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How To Use This Book 


This Program Logic Manual describes in detail the internal 
specifications and logic of the IBM System/370 and Sys- 
tem/360 Operating System (OS) and Disk Operating System 
(DOS) programming support for the IBM 3735 Program- 


mable Buffered Terminal (hereafter referred to as the 3735). 


The 3735 programming support includes both Form De- 
scription (FD) macro instructions and Form Description 
utility programs to provide the operating environment for 
applications using preprinted (fixed-format) forms and 
batch processing. 

This publication is divided into four major parts: Part 1 
gives an overall introduction to the 3735; Part 2, the Form 
Description macros information; Part 3, the Form Descrip- 
tion utility information; and Part 4 contains the rear matter 
of the appendixes and glossary. The 3735 FD macros and 
FD utility information contained in Parts 2 and 3 is directed 
to the IBM program systems representatives and system 
engineers who provide program maintenance and who need 
information about the internal organization and logic of 
the FD macros and FD utility. 

Because the OS and DOS programming support for the 
3735 are so similar, both are discussed as one. Where sig- 
nificant differences exist, they are explained as required. 

The second part of this book, dealing with the macros, 
is subdivided into three sections containing the following 
information. 

Section | is the Introduction to the FD macros. The 
general information presented in the introduction is basic 
to an understanding of the macros and includes descrip- 
tions of the following: (1) the macros themselves, (2) the 
general purpose of the macros, (3) the main functions of 
the macros, and (4) the system environment required to 
assemble the macros for both OS and DOS. 

Section 2, Method of Operation, describes the overall 
FD macro structure and the macro functions. It discusses 
in detail each function and the method used to accomplish 
that function. When appropriate, diagrams depict visually 
the concept being described. 

Section 3, Form Description Program Organization, 
describes the detailed logical organization of the FD pro- 
grams that result from the assembly of FD macro instruc- 
tions. This section notes specific OS and DOS dependencies 
as they are required. 

The third part of this book dealing with the FD utility, 
is subdivided into six sections containing the following 
information. 


Section 1, Introduction to the FD utility, contains gen- 
eral information that is basic to an understanding of the 
utility and includes descriptions of the following: (1) the 
utility , (2) the general purpose of the utility, (3) the main 
functions of the utility, (4) the system environment re- 
quired to execute the utility for both OS and DOS. 

Section 2, Method of Operation, describes the overall 
logical flow and functions for the utility. It discusses in 
detail each function and the method used to accomplish 
that function. When appropriate, diagrams depict visually 
the concept being described. 

Section 3, Program Organization, describes the detailed 
logical organization of the FD utility and includes flow- 
charts to illustrate the logical flow of the utility. This sec- 
tion denotes specific OS and DOS dependencies as they 
are required. 

Section 4, Directory, defines the CSECT names and 
other references used for the FD utility. It also provides 
cross-references applicable for the utility program listings. 
All this information is presented in charts and tables. 

Section 5, Data Area Layouts, refers back to Section 2 
and Section 3, which describe graphically and verbally the 
format and contents of the various data areas used by the 
FD utility. 

Section 6, Diagnostic Aids, is not provided because of 
the simplicity of the programs. 

The fourth major part of this publication contains four 
appendixes and a glossary of definitions for the technical 
terms used in this book. 

To understand the logic of the 3735 programming sup- 
port, the reader must have a general understanding of the 
System/370 or System/360 Operating System or Disk 
Operating System and of the macro language facility of 
the assembler. In addition, he should also be familiar 
with the following prerequisite publications: 

IBM 3735 Programmable Buffered Terminal 

Concept and Application, GA27-3043 

Programmer’s Guide, GC30-3001 
IBM System/360 Operating System Assembler Language, 

GC28-6514 
IBM System/360 DOS, TOS Assembler Language, 
GC24-3414 
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The IBM 3735 Programmable Buffered Terminal provides 
an effective means of manipulating the data required for 
day-to-day business operations. The 3735 brings many of 
the capabilities of the central computer to the operator, 
thereby allowing the terminal to automatically provide 
operator guidance, error detection, formatting, editing, 
and other services. 

The IBM 3735 Programmable Buffered Terminal is a pro- 
grammable terminal consisting of the IBM Selectric® I/O II 
Keyboard Printer and a highly sophisticated desk-side con- 
trol unit. It is designed primarily for applications that use 
preprinted (fixed-format) forms and batch processing. 

The 3735 uses two levels of program control. First, the 
user generates Form Description (FD) programs, via the FD 
macros and the FD utility, to specify the functions desired 
for processing a specific type of form. Second, a microcoded 
terminal control program, recorded in the terminal control 
unit during manufacture, interprets the FD programs and 
provides detailed terminal control. 

The Form Description (FD) macros assembled by the 
host operating system describe the forms to be processed. 
The Form Description (FD) utility arranges the forms for 
later transmission to the 3735 via the user’s application 
program and teleprocessing access method. The FD pro- 
grams reside in the 3735 terminal until replaced by the 
user. 


CONFIGURATION 


The 3735 is a supported device for the IBM System/370 
Model 135 and up and for the IBM System/360 Model 22 
and up. The basic 3735 terminal configuration provides 
for communication over point-to-point switched (dial-up) 
or nonswitched (with multipoint control) common-carrier 
facilities at speeds of 1200 or 2000 bits per second. (World 
Trade provides for a 600 bits-per-second transmission 
speed.) Communication over multipoint nonswitched 
(leased) lines at 1200, 2000, or 2400 bits per second can 
be provided by the addition of a special feature to the 
basic 3735 terminal. 

The basic configuration of the 3735 consists of an IBM 
Selectric® I/O II Keyboard Printer and desk-side control 
unit. The control unit consists of (1) a small processor, 

(2) a binary synchronous communication (BSC) line adapt- 
er, and (3) a non-removable magnetic-disk storage device. 
The magnetic-disk storage device within the control unit 
contains (1) the terminal control program, (2) the FD pro- 
grams, (3) an inquiry message or response, (4) user-generated 
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data records, and (5) (optionally) a CPU ID list. The num- 
ber of FD programs, each representing a different form 
type, that can be stored depends on the length of the pro- 
grams. Basic storage capacity for user FD programs and 
data storage is about 62K bytes. This basic capacity is 
expandable in increments of 42K bytes to a total of about 
145K bytes. 

This storage capacity is provided in 22K-byte tracks, each 
of which is divided into forty seven 480-byte sectors. The 
basic 3735 terminal has three tracks for storing the FD pro- 
grams and user data. Three sectors of each of these tracks 
are reserved for control purposes, and four bytes of each of 
the remaining sectors contain chaining information. In the 
sectors that store FD programs, 234 bytes contain the pro- 
grams and six bytes contain chaining information. The re- 
maining 240 bytes of FD program sectors on disk are not 
used. When in the buffer, the terminal control program 
uses the second half of these bytes as work space. 

Three optional features provided for the 3735 are the 
IBM 5496 Data Recorder, the IBM 3286 Printer Model 3, 
and the IBM Operator Identification Card Reader attach- 
ments. The 5496 is a buffered operator-oriented, key-entry 
unit used to punch, interpret, and read the 96-column 
punched card. The 3286-3 is a printer adapter used as a 
secondary printing device. The identification card reader 
reads magnetically recorded data from the IBM 16-character 
ID card (standard credit card size 2-1/8” x 3-3/8”) that has 
a magnetic stripe and from the other IBM credit card with 
data up to 39 characters. 


PROGRAM SUPPORT 


The IBM System/370 and System/360 support the 3735 
under the Operating System (OS) and the Disk Operating 
System (DOS). This support provides (1) for generating 
FD programs, (2) for preparing these programs for trans- 
mission te the terminal, and (3) for transmitting data 
between the computer and the terminal. 

The 3735 terminal uses the binary synchronous method 
of communications line control (BSC), making the terminal 
compatible with most BSC systems and programs. Since 
the 3735 is a BSC device, the binary synchronous support 
that exists in OS TCAM and BTAM and in DOS BTAM is 
sufficient to handle the transmission of data between the 
CPU and the terminal. 

The FD programs are generated using System/370 and 
System/360 OS and DOS Assembler Language macro 
instructions. These FD macro instructions provide error 
checking for the user. 
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A Form Description utility is provided to prepare the FD 
programs for transmission to the 3735. The FD programs 
are placed in an output data set for selection and transmis- 
sion by the user’s application program. When the terminal 
receives these programs, they reside on the 3735 disk and 
the operator uses them to control terminal functions. The 
FD utility operates under OS and DOS. It operates inde- 
pendently of the user’s teleprocessing program but is depen- 
dent upon the assembly of the FD macro instructions. The 
utility is scheduled through the input job stream. 

The minimum system that can use the FD macros and 
the FD utility is: 


OS/DOS — System/370 Model 135 
OS — System/360 Model 40, 128K 
DOS — System/360 Model 22, 32K 


Note: DOS requires 32K bytes of storage to support tele- 
processing. 


SYSTEM CONSIDERATIONS 


The following paragraphs outline functions that can be 
specified for processing a given form and discuss the for- 
matting of data transmitted to and received from the CPU. 


Forms Design 


The 3735 places few restrictions on forms design. The 
standard platen accommodates forms up to 15 inches wide 
with up to 130 characters per line. Printing is at ten char- 
acters per inch; vertical spacing is at six lines per inch. An 
original and up to four carbon copies can be printed. 


Form Descriptions 


Form descriptions should be developed sequentially from 
left to right, top to bottom, and page by page, since forms 
are usually processed in this manner during preparation. 

The 3735 form descriptions are presented in the follow- 
ing sequence: 


form: Descriptions that apply to the overall form. 

Page: Descriptions that apply to a single page of the 
form. 

Line: Descriptions that apply to a single line of the 
form. 

Field: Descriptions that apply to a single field of the 
form. 

Control: Descriptions that define the status checking 
and processing to be done on the form. 


Form 


The form description (specified by using the FDFORM 
macro) must name the form and specify a three-digit iden- 
tifier. The terminal operator uses this identifier to call out 
the form description program for processing a document. 
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The user can specify an operator message for the form. 
This message is included within the body of the FD program 
and can be requested by the terminal operator before begin- 
ning processing under FD program control. The message 
may include instructions for document preparation, machine 
setup, application name, and so forth. 

The form description can indicate the tab settings to be 
used during processing of the form. Each tabular stop is 
indicated by listing the character position (relative to the 
form) at which the stop is to be set. The terminal operator 
can perform a tab set routine, under FD program control, 
before starting to process forms under this FD program. 

The form description can specify the left margin stop 
that is to be used when processing the form. The margin 
stop is indicated by specifying, relative to the form, the 
character position in which the terminal’s left mechanical 
margin stop is to be set. The position (n) may range from 
0 to 129; the default isO. Actual output operation can 
begin in position n+1. 

The form description can indicate the format of data rec- 
ords created by an FD program before being sent to the cen- 
tral computer. This format can be described via one of two 
packing (condensing) functions: one that deletes consecu- 
tive trailing blanks and one that both deletes consecutive 
trailing blanks and inserts a separator character between 
data fields. If the data record format is to be sent to the 
CPU in its entirety, the form description can indicate that 
no packing function is to be performed. The packing option 
selected remains in effect throughout the processing of the 
entire form. 

The form description can indicate that a 96-character 
read buffer and a 96-character punch buffer are to be 
treated as a single 192-character read/punch buffer for tem- 
porary data storage for the optional 5496 Data Recorder. 

If the read/punch buffer is used for either a read or a punch 
operation for the 5496, the form description can indicate 
explicitly the location in the buffer to be read or punched. 
The form description can also vary the checking of the 
3286-3 line printer buffer. The line printer buffer can also 
be used to print on the 3286-3 provided the location to be 
written from is specified explicitly in the form description. 

The form description also can indicate that the user may 
specify Katakana instead of ASCII code in processing forms. 


Page 


The page description (specified by using the FDPAGE 
macro) provides identification and size information about 
a single page of the form. The size information is used 
during generation of the FD program to ensure that the 
fields and lines of the form will fit the page size intended. 
If the form consists of more than one page, each individ- 
ual page must be described. If a single page is used, the 
page description can be included with the form description. 
Line and field descriptions for the page follow each page 
description. 


Each page description identifies the page being described 
by number and optionally by name. Page numbers are 
normally in ascending sequence but need not be consecu- 
tive. 

The overall height of the page is described by indicating 
the total number of usable line positions on the page; for 
example, a page 11 inches long has a height of 66 (at six 
lines per inch). 

Vertical margins indicate the first line and the last line 
which may be defined. Vertical margins are indicated by 
line number, counting from the top of the page; for exam- 
ple, if the first line on a form may be the fourth line from 
the top, and the last line may be the 64th line, the vertical 
margins are 4 and 64. 


Line 

Line descriptions (specified by using the FDLINE macro) 
describe each line to be processed within a page. A line 
description, identified by a line number (represented by a 
number from 1 to n for each page on a Selectric or by an 
accumulative number for a page on a matrix printer), should 
be provided for each line to be processed by the 3735. 

The line description defines the line’s horizontal space 
requirements. Each line description contains a line identi- 
fication, width, and horizontal margins. If the width and 
horizontal margins of all lines on a page are the same, these 
descriptions can be included with the page description. 

If FD program control for a series of lines is identical, 
the series can be designated for cycling. Repeating line and 
field descriptions for each line is then unnecessary. Describe 
the first line or group of lines and indicate the number of 
repetitions. In addition, indicate the part of the form 
description program to be processed following the cycle. 
This cycle control is desirable for two reasons: it shortens 
the FD program, thus saving storage space on the 3735 
disk; and it allows the operator to terminate cyclic opera- 
tion if all lines are not required on a specific transaction. 


Field 


Field descriptions (specified by using the FDFIELD macro) 
follow each line description and specify the control desired 
for each field of the line. Many commonly used functions 
(such as, centering data within a field, comma and decimal 
point insertion, and self-check number verification) have 
been implemented within the terminal control program. 

The field’s horizontal position on the line identifies each 
field description. This field is expressed as the first (left) 
and last (right) character positions of the field or, option- 
ally, as the first character and length. Maximum field size 
is 127 characters. 

Field descriptions tell where the data comes from 
(source), what is done with it (operation), and where it is 
to go (sink). The operator can specify a variety of checking 
functions for the input data. The application program pro- 
cesses the source data as required by using arithmetic and 


compare functions. Several devices can be specified for the 
destination (sink) of data from the specified source: 


@ the Selectric® I/O II printer 
@ an inquiry buffer (INQ) 

@ the IBM 5496 Data Recorder 
@ the IBM 3286 Printer Model 3 


The Selectric® I/O II keyboard and the IBM Operator Iden- 
tification Card Reader are also supported devices for the 
origination (source) of data. 


Control 


This description (specified by using the FDCTRL macro) 
provides for (1) testing of logical conditions (indicators), 
(2) modifying the content of indicators and counters, and 
(3) executing commands and nonsequential operations. 
Use of these logical and arithmetic functions can imple- 
ment such functions as field skipping. The forms designer 
should define the function desired and the data available; 
this allows the macro encoder to implement an FD pro- 
gram that provides exactly the functions desired. The con- 
trol description also includes card reading and punching 
instructions. A read card instruction signals the 5496 card 
reader to read a card and the data enters a card-image buf- 
fer where it is available for use by the FD program. Simi- 
larly, a punch card instruction signals the 5496 punch to 
accept data from a card-image buffer, and punch the data 
into a card. 


PROGRAMMING CONSIDERATIONS 
Form Description 


Assembly of Macro Instructions 


The System/370 and System/360 OS and DOS Assembler 
Language macro instructions provide the user with a means 
of describing his forms. The output of the system assembly 
is an object module suitable for input to the FD utility. 
Also produced is an assembly listing that includes diagnos- 
tic and error information concerning the macro instructions. 
The assembly provides the following functions: 


@ Check input statements for completeness and accuracy. 


@ Provide meaningful comments to aid in debugging the 
program. 


@ Calculate sequences of motion control characters for 
proper print-element positioning. 


@ Sequence-number output records (object module). 


@ Set flags in the output if the input statements contain 
errors that invalidate the output. 


The output of the assembly is object modules whose data 
portions are unpacked FD programs. These object modules 
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can be punched in cards or written ina data set as card 
images, then used as the input to the FD utility. 


Utility 

The FD utility prepares the unpacked FD programs for 
transmission to the 3735 terminal. The utility operates 
basically the same under OS and DOS. It reads the output 
of the assembly from a card reader or equivalent sequential 
input device, checks for program integrity, and arranges the 
unpacked FD programs into blocks of 476 bytes. Then the 
utility writes these unpacked FD program blocks into a 
user-specified data set that is available to the user’s appli- 
cation program. 

The main storage required by the OS FD utility is no 
more than that required for the minimum OS Linkage 
Editor available to the system. The main storage required 
by the DOS FD utility exclusive of the Linkage Editor step 
is no more than 12K bytes. The following three I/O devices 
are required: a card reader or equivalent device; a printer; 
and a direct-access storage device (DASD). The utility uses 
no more than 10 tracks of 2311 storage, or the equivalent, 
for program residence. The user’s secondary storage re- 
quirements depend on the number, size, and complexity of 
the forms being described. 

The FD utility is scheduled through the input job stream, 
encompassing three sequential job steps: Control, Linkage 
Editor, and Storage. There is one optional feature: in OS, 
the JCL PARM feature; in DOS, the RPLACE control card. 

In OS, if a form is a duplicate (one with the same form 
name) of a member in the user’s output data set and the 
REPLACE option has not been specified, the form is stored 
as a new member under a temporary name: for example, 
IDFTEMPO, IDFTEMP1, IDFTEMP2,..., IDFTEMP9. If 
these temporary names have already been exhausted, the 
new member is not stored. The form is replaced if the 
REPLACE option has specified that all duplicates are to 
be replaced, or has specified, by name, the forms to be 
replaced. The action taken is noted in the listing. 

In DOS, if a form is a duplicate of a member in the user’s 
output data set and the RPLACE card has not been used, 
the form is stored as a new member under a temporary 
name: for example, IJLFTMOO, IJLFTMO1, ISLFTMO2, 
...,IJLFTMO9. If these temporary names have already 
been exhausted, the new member is not stored. The form 
is replaced if the RPLACE card has specified that all dupli- 
cates are to be replaced, or has specified, by name, that the 
form be replaced. The action taken is noted in the listing. 

To include the FD utility in his operating system, the 
user must copy it from the component library on which it 
is distributed. This may require allocating additional space. 
Prior to the execution of the FD utility, the system pro- 
grammer must ensure that suitable input and output data 
sets are designated through correct coding of the job con- 
trol statements. 
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If an uncorrectable error is encountered, the FD utility 
takes the appropriate action, depending on which step of 
the three-step sequence is being executed. The control step 
terminates the job step; the storage step deletes a partially 
created sequence of blocks from the user’s data set. Each 
of the three steps produces a diagnostic listing. The listing 
produced by the last step names each unpacked FD pro- 
gram that was added to, deleted from, or not added to the 
user’s data set. 

The response to environmental errors arising from im- 
proper input, such as a card missing or out of sequence, is 
to write a message in the diagnostic listing, produced in the 
control step, and to exit. Input following the erroneous 
card is not processed. The response to errors such as insuf- 
ficient allocation of space in a data set is to terminate pro- 
cessing and to note the condition in the listing. The re- 
sponse to implementation errors, such as errors in system 
control blocks, is those error recovery and termination 
options provided by OS and DOS. 

The diagnostic listing produced from the execution of 
each of the three utility job steps contains information of 
interest to the programmer adding, creating, modifying, or 
extending a set of unpacked FD programs and includes a 
list of messages. 

Following are some examples of the types of diagnostics 
noted in the listing: 


Successful completion 

Last valid record (card) number 

Erroneous record (card) number 

Invalid sequence number 

Invalid deck ID 

Premature end-of-file 

Invalid card type 

Name of FD program stored 

Duplicate name, if it was stored and if so, under 
what name 

Insufficient space 


The messages that are listed vary slightly between OS and 
DOS. The programmer response to any errors indicated is 
to correct the error and re-execute the job. Another alter- 
native is for the utility to note the error and continue pro- 
cessing the next valid data group. 


Transmission 


The output of the FD utility consists of 476-byte blocks 
containing macro-generated bit strings forming the data 
portion of FD messages. These FD programs containing 
the unpacked code that is interpreted at the 3735 reside 
in a user’s data set. The user must create a teleprocessing 
application program to select and transmit the FD pro- 
grams, just as he must create application programs to pro- 
cess the data captured and transmitted by the 3735 
terminals. 


Not all FD programs in the user’s library must be trans- 
mitted to all 3735 terminals during FD program transmis- 
sion to individual terminals. The user can be selective, 
sending FD programs from the library to specific termi- 
nals. However, during transmission of the FD programs 
from the user’s data set to the terminal, all the FD pro- 
grams that are to reside at a terminal must be transmitted 
at the same time. FD programs cannot be added to those 
already residing at the terminal. To get the total number 
of FD programs desired at the terminal, the FD programs 
already there must be retransmitted along with any addi- 
tional ones. 


The FD programs must be transmitted according to the 
following scheme: 


1. The 3735 terminal transmits its unpacked data to the 
CPU first. 

2. The CPU must transmit a user-prepared block which 
informs the 3735 that the following transmission blocks 
are FD programs. 

3. The CPU transmits the FD programs in 476-byte un- 
packed blocks. 

4. The CPU must transmit a user-prepared block that 
informs the 3735 that transmission of FD programs 
is complete. 
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Part 2 is designed to be used to trouble shoot, debug, and 
repair problems in the 3735 FD macro programming sup- 
port. The program listings of the macro expansions are 
much too lengthy for the user to find an error in a single 
statement within the internal code. For this reason, the 
user should perform the following analytical steps to find 
and correct errors. 


1. Verify that the user-specified FD macros are correctly 
coded. 

2. List the records created by the macro assembly using 
one of the sample programs described in Appendix G 
or Appendix H in the JBM 3735 Programmer’s Guide, 
GC30-3001. 

3. Verify that the records listed are correct. If they are 
not valid, alter the FD utility output with a temporary 
fix. Refer to Part 2, Section 3 for information about 
the FD program maintenance procedures to follow. 
Also, consult Part 2, Section 3 for the correct formats 
of the FCD bytes and immediate bytes that are needed 
for correct FD program execution. 


The information in this part of the book is subdivided into 
three main sections as follows. 


Part 2. Objectives 


Section 1 is the introduction to the FD macros and de- 
scribes in general terms the macros and their relationship to 
one another. The section discusses the system requirements 
needed to define and use the macros and the operational 
considerations of the macros (input and output of the FD 
macro assembly) including a brief explanation of the 
MNOTE messages generated by a macro assembly. 

Section 2 describes the method of operation that the FD 
macros use and includes a detailed explanation of the macro 
organization of inner and outer macros. Also discussed is 
the step by step procedure that takes place in the assembly 
of FD macros to generate an FD program. 

Section 3, Form Description Program Organization, 
explains in great detail each portion of an FD program and 
includes diagrams to aid in visualizing each byte generated 
by an assembly. The subjects discussed are the FD program 
header, the FCD bytes, the immediate bytes, and the FD 
program trailer. Following this information is a description 
showing how to diagnose and repair errors that appear in 
FD programs after the assembly process is complete. This 
discussion is very important to finding and correcting errors 
in the FD macro programming support. 
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Section 1. Introduction 


The Form Description (FD) macros are a unique family of 
IBM System/370 and System/360 OS and DOS Assembly 
Language macro instructions. They are designed to facili- 
tate the description of terminal-oriented data processing 
forms in terms of, (1) form structure, (2) data field attri- 
butes, and (3) the activities required of a sophisticated 
terminal and its operator in the processing of such forms. 
The FD macros are an interrelated group of macro state- 
ments that provide a symbolic means of describing to the 
3735 (1) the structure of a data processing form, (2) the 
characteristics of each data field of the form, and (3) the 
processing to be done on each data field. Assembly of user- 
specified sets of FD macros results in an object module 
made up of field control descriptors (FCDs) assembled 

in an unpacked (expanded) state. The text part of the 
object module is a collection of bytes that comprise one 
or more FD programs. The FD program object modules 
must be restructured into program blocks by the FD 
utility, which stores them on a direct-access storage 
device (DASD). Later these program blocks are selec- 
tively retrieved and transmitted to specified 3735 termi- 
nals. There they are stored on a magnetic-disk storage 
unit in packed (normal) form, to be recalled as needed 

by the terminal operator or by the terminal control pro- 
gram. The terminal control program interprets each 

set of program blocks as a set of directions for the pro- 
cessing of one type of form. Refer to Figure 2-1 for the 
logic flow of the 3735. 


FORM DESCRIPTION MACRO INSTRUCTIONS 


The FD macros are grouped into three classes: structural, 
procedural, and delimiting. The four structural macros are 
FDFORM, FDPAGE, FDLINE, and FDFIELD. The pro- 
cedural macro is FDCTRL and the delimiting macro is 
FDEND. 

Two optional macros available for diagnostic aids are 
FDTRACE and FDDSPLY. These two macros can be 
included with the specifications on the FD macros or added 
to the internal code. 


The Structural Macros 


The structural macros are hierarchical in character, which 
restricts the order in which they may be coded. The forms 
encoder must therefore think of his forms in terms of an 
information structure in which forms are made of pages, 
pages are made of lines, lines are made of fields, and fields 
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are made of characters. The structural macros describe the 
structural organization of the form and the processing re- 
quired by each field. They are normally coded so as to 
maintain forward progression through the entire form; for 
example, from top to bottom on a page, and from left to 
right on a line. 

The structural macros are designed to take advantage of 
the promotability of many of their keyword operands. 
Promotability is the ability of a keyword operand to be 
coded in some particular macro instruction (for example, 
FDFIELD, FDLINE, FDPAGE) and also to be coded in 
one or more macros of higher authority. The authority of 
a macro statement extends through an FD program until 
the same type of macro statement (or one of higher author- 
ity) appears later in the FD program. This concept allows 
a number of the attributes of pages, lines, and fields to be 
coded at a structural level higher than their minimum level 
of applicability, and, optionally, to be temporarily over- 
ridden at a lower level. Thus, the ability to promote an 
operand helps to minimize the total amount of encoding 
required to describe a form. 


The Procedural Macro 


The procedural macro instruction FDCTRL enables the 
forms encoder to request that the IBM 3735 test the status 
of one or more terminal control program indicators, also 
called logic switches. In the FDCTRL macro the encoder 
may request unconditionally (if no test was coded) or con- 
ditionally (based on the result of the test) that any combi- 
nation of the following actions be taken: 


@ Modify the status of one or more program logic indi- 
cators. 


@ Perform clearing and/or arithmetic operations on 
terminal counters. 


@ Perform clearing on terminal storage. 


@ Read into, punch from, and/or clear unit-record data 
buffers. 


@® Connect and disconnect the communication line for 
inquiry/response purposes. 


@ Alter the sequence in which elements of the form are 
processed. 


@ Position the 3286-3 Printer to a new line for printing. 


FDCTRL macros may appear in any location within the FD 
macro statements that describe a specific form. 


The Delimiting Macro The Trace Macro 


The delimiting macro FDEND closes the description of each There is in addition to the required FD macros an optional 
form and prepares for a form description that may follow diagnostic macro named FDTRACE. This macro provides 
by (1) confirming that no source statements have been lost, for the user the ability to trace the activity that occurs 

(2) completing code generation, and (3) reinitializing the during the processing of each FD macro. For further infor- 
global variables used in the internal processing. mation refer to Part 4, Appendix B of this book. 
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Figure 2-1. 3735 Program Logic Flow 
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The Display Macro 


The optional display outer macro FDDSPLY activates the 
IDFDSP inner macro, which displays the information re- 
quested in the call of IDFDSP. For further information 
refer to Part 4, Appendix B of this book. 


Form Description Macro Organization 


An ordered set of FD macros collectively define a form 
structure with the following characteristics: 


@ The type (FDFORM, FDPAGE, and so forth) of FD 
macro determines the structural level of the macro. 


@ The structural level of the macro determines, in turn, 
the scope of the macro and of its keyword operands. 
The scope of a structural macro is that portion of the 
form description beginning with the macro statement 
itself and continuing to, but not including, the first 
equal or higher structural level. 


@ The form structure allows the FD macros to generate 
explicit sequences of output-element position-control 
information needed to locate successive fields in the 
forms being processed. 


Each FD macro consists of three logical divisions, which 
may be physically distributed: operand validation, param- 
eter establishment, and field control descriptor generation. 

The operand validation section of an FD macro tests the 
value of each operand coded (or the default value) in the 
present occurrence of the macro. If this section identifies 
an error, it issues an appropriate MNOTE message. The 
MNOTE messages used by the FD macros provide diag- 
nostic information regarding coding errors in the user FD 
macro statements and provide descriptive information 
for verifying the correctness of each macro specification. 

The parameter establishment section of an FD macro 
statement establishes the form description program param- 
eters from either coded or default values and saves them 
in global variables for subsequent reference and assembly 
by other FD macros. 

The field control descriptor generation section of an FD 
macro composes the field control descriptor (FCD) that is 
the FD program. It performs (1) the generation of control 
information for the FD utility, (2) the resolution of sym- 
bolic references, and (3) the generation of the FCD data. 
The 3735 terminal interprets this data as directions for the 
processing of one data field or the performance of one con- 
trol operation. 

In some cases, the macros reserve space in the assembled 
data for unresolved references and save the location at 
which the reference occurred. When the FD macro that ~ 
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resolves the reference is encountered, the macro inserts 
the resolved reference in the required position by means 
of the backward origin facility of the assembler (ORG 
statement) and deletes the saved location. The maximum 
number of concurrent unresolved references that the FD 
macros are designed to accommodate within any one form 
description is 64. 

The FD macros manipulate global variables to record the 
assembly status (whether in form mode or not), structural 
level, and the occurrence of aCYCLE operand. Global 
variables are values assigned to SET symbols in one macro 
definition used to vary the statements that appear in other 
macro definitions. These variables enable decisions to be 
made whether each FD macro statement is coded in a per- 
missible relation to the others, and whether it is suitable 
for use as a CYCLE limit or target, or as a GOTO target. 
Additional global binary switches record the occurrence of 
a serious error, so that further generation of useless code 
may be suppressed. 


SYSTEM REQUIREMENTS 


In order to use the FD macros, a user must have a host 
operating system (IBM System/370 or System/360 OS or 
DOS) with an assembler and a macro library to contain 
the FD macros. The operating system must contain at 
least 128K bytes of storage space for OS or 32K bytes 

for DOS in order to use the FD macros and the FD utility. 
DOS requires 32K bytes of storage to support telepro- 
cessing. 

Any set of FD macro statements can be assembled by 
any DOS or OS assembler. The assembler must have access 
to a macro library containing the FD macro definitions. 
These definitions must be appropriate for the operating 
system on which the FD program object modules are to 
be processed and used. If the FD macros are not in the 
macro library, the assembler generates error messages indi- 
cating undefined operation codes. Changing from DOS 
to OS or vice versa requires no recoding, merely reassem- 
bly, provided that the code does not exceed the capacity 
of the assembler. 

The assembly of FD macros generates object modules 
that support the functions of the 3735 control program 
performed under FCD control. An FCD is that part of a 
3735 FD program that the 3735 interprets as the directions 
for the processing of one data field or the performance of 
one control operation. An FD program is a set of control 
data bytes that collectively describe to the 3735 terminal 
the activity required to process one specific type of form. 


OPERATIONAL CONSIDERATIONS 


This section describes, in general terms, the input to, and 
output from, the FD macro assembly. 


Input and Output of the Form Description Macro Assembly 


Input 


The input for the FD macro assembly consists of one or 
more ordered sets of FD macro instructions, each set 
describing one form required for a data processing appli- 
cation, beginning with an FDFORM statement and ending 
with an FDEND. The macros do not generate executable 
code. They are first assembled into object modules of FD 
programs; these programs are input to the FD utility. The 
utility prepares the resulting FD programs for being sent 
to the 3735. The 3735 executes the FD programs via the 
terminal control program interpretive routines. 

The FD macro instructions have no direct connection 
with normal system operation characteristics such as, link- 
ages, return codes, completion codes, abnormal termination, 
or wait states. They use MNOTE severity codes similar to 
those of other macro instructions of the host operating sys- 
tem. The MNOTE messages provide diagnostic information 
regarding coding errors in the user’s FD macro statements 
and provide descriptive information for verifying that each 
macro specification is correct. 


Output 


MNOTE Messages: The MNOTE severity codes generated 
by the FD macros as output on the assembly listings are 
indicated below with their meanings and typical uses. 


* Information only; not treated as an error by the assem- 
bler. Typical use: to print the attributes of the form, 
page, line, or field. 


0 Mild warning; the condition described is unexpected, 
but cannot be confirmed as an error. Typical use: to 
indicate that an operand contains excess suboperands 
or characters. The FD macros make no assumptions of 
operand values and ignore the excess suboperands or 
characters. 


co 


Severe warning: the condition described constitutes a 
confirmed error that invalidates the current form (but 
not the other forms in the same assembly). Operand 
checking may continue for the invalid form. Typical 
use: to indicate that the FDEND macro has been pro- 
cessed, leaving one or more forward references unre- 
solved. 


The return code from the assembly step equals the high- 
est MNOTE severity code produced in the current assembly. 
In an IBM System/370 or System/360 OS system, the job 
control COND operand of the EXEC statement may be used 
to halt the job on severity code eight. The output of an 
assembly that incurred a severity code of eight is not usable 


and cannot be processed correctly by the FD utility or the 
3735. In an IBM System/370 or System/360 DOS system 
the results of the assembly must be inspected for freedom 
from error before the results can be further utilized. 


Object Module: The output from an assembly of a set of 
FD macro statements is a listing of the input (the FD 
macros) and the results, together with an object module 
comprised of ESD, TXT, and END records. The text part 
of the object module contains FD programs (keyed un- 
packed FD program blocks and control information) made 
up solely of nonrelocatable absolute-valued constants. 
Refer to Figure 2-2 for the OS diagram of FD macro assem- 
bly output or to Figure 2-3 for the DOS diagram of FD 
macro assembly output. 


Control Sections: The assembly of a set of FD macro 
source statements generates one or more control sections. 
Each of the control sections (with the possible exception 
of the last, which may be shorter by a multiple of 486 
bytes) is 2920 bytes long (for OS) or 1464 bytes long 
(for DOS). The control section is subdivided into 486-byte 
items called keyed unpacked form description program 
blocks (KUPBs), plus a four-byte (for OS) or six-byte (for 
DOS) end-of-assembly indicator. The end-of-assembly indi- 
cator tells of the presence or absence of additional control 
sections. This indicator is set to all zeros for all but the 
last control section, for which it is set to all ones. Refer 
to Figure 2-4 for the format of the OS control section or 
to Figure 2-5 for the format of the DOS control section. 
Each KUPB consists of a 10-byte key field and a 476- 
byte unpacked program block (UPB). Within the key field 
are two subfields: (1) an eight-byte name subfield and 
(2) a two-byte count subfield. Within the UPB field are 
two more subfields: (3) a 470-byte data subfield and 
(4) a six-byte end-of-form subfield. The subfield con- 
tents follow: 


1. The name subfield contains the form name, left justified 
and padded to the right with blanks, as needed. This is 
the name by which the FD program will be known in 
the user’s FD program library. 

2. The count subfield commences with a binary zero and is 
incremented by one in each KUPB within a single FD 
program. However, if there was an error in the assembly 
of the program, this subfield contains a binary -1 
(X‘FFFF’). If the assembled program is incomplete, 
this subfield contains a binary -2 (X‘FFFE’). 

3. The data subfield contains the actual instructions that 
are sent to the 3735 to control the terminal’s actions 
during forms creation and data capture. The first 2 
bytes of this subfield contain X°4070’ used for head- 
sector backward chaining on the disk sector. 

4. The data in the six-byte end-of-form subfield is also 
sent to the 3735. This subfield is set to all zeros in every 
KUPB except the last one in an FD program. In the last 
KUPB, it is set to all ones to indicate the end of the FD 
program. 
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Figure 2-6 illustrates the format of the KUPB and the UPB. As the FD macros generate an FCD, they update a global 


The first control section resulting from an FD macro count of bytes. When a multiple of 470 is reached, the 
assembly in OS is named IDF1000. Subsequent control macros Clear the counter and generate 3X‘0000’. Next, the 
sections are named IDF1001, IDF1002, and so forth, by macros generate from globals a form name subfield and a 
incrementing the control section counters in the FDFORM count subfield. At form’s end, the macros pad out the cur- 
macro. The first DOS control section is named IJLF1000, rent KUPB if incomplete, and generate 3X°FFFF’. 
with subsequent control sections named IJLF1001, To avoid a nonproductive read operation, the user’s 
IJLF1002, and so forth, by incrementing the control sec- application program can examine the end-of-form subfield 
tion counters in the FDFORM macro. when retrieving the successive unpacked program blocks for 

FDFORM 
FDPAGE 
FDLINE 
Macro FDFIELD 
Instructions 
eee Op eres FDCTRL 
FDEND 
Input 
OS 
piScens ng Assembler 
IDFinnn 
Output 
1DF1001 
1DF 1000 
Control 
Sections 


End-of-Assembly 
Indicator 


Figure 2-2. OS FD Macro Assembly Output 


transmission to a 3735 terminal. In DOS, this examination 
must be done because the FDutility will have stored the 

UPBs in an indexed sequential data set, and the end of a 
form will generally not coincide with an end-of-file indi- 
cation. 

Although only the first 470 bytes (the data subfield) of 
each UPB are significant to the 3735, it is more convenient 
to transmit the entire 476 bytes, since this size of I/O area 
is required for each data block received from the 3735. 


Segments and Paths: The listing from the assembly of an 
FD program divides the program into paths and segments. 


FDFORM 

FDPAGE 
Macro FDLINE 
Instructions 

FDFIELD 

FDCTRL 
Input FDEND 


DOS 
Assembler 


Processing 


Control 
Sections 


Information about the paths and segments helps verify the 
correctness of the resulting FD program and trace the se- 
quence of actions if the FD program produces unexpected 
results at the 3735 terminal. 

Several actions create a path: 


@ The start of the FD program 


@ The encoding of the SAVELOC operand outside of a 
cycle 


@ The joining of two paths 


The segments of each path are numbered in ascending order 
beginning with one and increasing to 255. Each segment 


End-of-Assembly 
Indicator 


Figure 2-3. DOS FD Macro Assembly Output 
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transfers control either to another path or to a higher- 
numbered segment in the same path. If a path is ever en- 
tered, the 3735 always executes unconditionally the first 
segment of that path. The remaining segments of that 
path are executed conditionally or unconditionally with 
respect to the first segment. If the first segment of a path 
is not executed, no part of that path is executed. If the 
first segment is executed, all provisionally unconditional 
segments that follow are executed. Then, if their specified 
conditions are met, the following conditional segments are 
executed. A path ends when one of the following situations 
occuls: 


@ The start of another path 
@ The end of the FD program 


@ The occurrence of an unconditional STOP or CANCEL 
command 


Several conditions create the segments comprising a path: 


@ The start of a path 

@ The issuance of a branch (for example, GOTO) 
@ The creation of a cycle 

@ The encoding of SAVELOC within a cycle 


@ The macro following the limit of the cycle (the post- 
limit macro) 


@ The joining of several segments in the path 


Segments and the actions occurring within them are condi- 
tional or unconditional as explained in the previous para- 
graph. | 

At the end of each path, MNOTE messages describe the 
indicators, buffers or devices, and the counters used in the 
path. The MNOTE messages indicate warnings describing 
possible erroneous use of these storage areas at the end of 
a path or when the error condition occurs. Two such 
errors are as follows: 


@ Requesting output from a buffer that has no previous 
reference to it in the path 


@ Loading a buffer and not getting the output from it 
before the path ends 


MNOTE messages indicate the transfer of control between 
paths and segments when the branches are resolved at the 
end of each path. 

Proceed to the next section of Part 2 for an explanation 
of the FD macro structure and more detailed information 
about the FD macro assembly process. 


2916 *End-of-Assembly 
Indicator 
2919 (B67) 


*2X‘0000' - Another block follows. 
2X'FFFF'’ - This is last block. 


Figure 2-4. OS Control Section Format 
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—_—___________—— 486 Bytes $+ 


O (0) 
486 (1E6) 
972 (3CC) 
1458 (5B2) *End-of-Assembly 


Indicator 
1463 (5B7) 


*3X‘0000’ - Another block follows. 
3X‘FFFF' - This is last block. 


Figure 2-5. DOS Control Section Format 


Bytes 


Name Subfield 
(same within 
each unpacked 
program) 


Data Subfield 


Key Field Form Description Unpacked Program Block (UPB) 


H‘OO’ - First KUPB 
Incremented by 1 to end of 
unpacked program; set to 
-1 and -2 for errors 


3H‘00’ - All KUPBs except the last 
3H’-1' (3X‘FFEFF’) - Last KUPB of Form 


Figure 2-6. Keyed Form Description Unpacked Program Block (KUPB) 
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Section 2. Method of Operation 


FORM DESCRIPTION MACRO STRUCTURE 


The FD macro instructions are grouped into three classes; 
structural, procedural, and delimiting. The four structural 
macros (FDFORM, FDPAGE, FDLINE, and FDFIELD) 
describe the structure of a data processing form and the 
characteristics of each data field of the form. The proce- 
dural macro FDCTRL regulates terminal operations that 
are not uniquely associated with the processing of data 
within a specific document field. The delimiting macro 
FDEND closes the description of each form and prepares 
for a form description that may follow. 

In addition to these standard FD macros, the optional 
diagnostic macros, FDTRACE and FDDSPLY, provide 
valuable debugging tools. For further information refer 
to Appendix B in Part 4 of this book. 

Eleven operands in the four structural macros are 
promotable: 


PAGE HEIGHT=,VMRG=; 
LINE WIDTH=,HMRG=; 
FIELD SOURCE=,KIND=,SELFCHK=,SINK=; 


JUSTIFY=,FILL=,UL=. 


The SOURCE=‘string’ operand specification is the exception 
in the promotable SOURCE options and is not promotable. 
These operands, of course, can be specified in the FDFORM 


macro, thereby minimizing the amount of coding required 
by the encoder. 
Eleven operands are not promotable: 


PAGE page number,SAVELOC=; 
LINE line number CYCLE=,SAVELOC=; 
FIELD CYCLE=,PICTURE=,IN D=,CTR=; 


COUNT=,COMPARE=,SAVELOC=; 
BATCH=,field boundaries. 


The SAVELOC= operand can be coded for all of the struc- 
tural macros except FDFORM, although it is not promot- 
able. The CYCLE= operand, also not promotable, can be 
coded for the FDLINE, FDFIELD, and FDCTRL macros. 
The programming support for the 3735 Form Descrip- 
tion macro instructions is composed of an organization of 
nested macro statements. The six FD macro statements— 
FDFORM, FDPAGE, FDLINE, FDFIELD, FDCTRL, and 
FDEND—comprise a group called outer macros, macro 


inner macros for OS and of the IJLFINO1, IJLFINO2, 
IJLFINO3, IJLFINO4, IJLFINOS, IJLFINO6, IJLFINO7, 
IJLFINO8, IJLFINO9, IJLFIN10, IJLFIN11, IJLFTR, 
IJLFASM, IJLFMSG, IJLFMSG1, IJLFMSG2, and 
IJLFMSG3 inner macros for DOS. These macros are here- 
after referred to as the INO1, INO2, INO3, INO4, INOS, 
INO6, INO7, INO8, INO9, IN10, IN11, TR, ASM, MSG, 
MSG1,MSG2, or MSG3 macros. The global variables re- 
quired by both the outer macros and the inner macros 
for their processing are contained in the IDFGBL copy 
book for OS or in the IILFGBL copy book for DOS (here- 
after called the GBL copy book). The first statement of 
every macro is COPY IDFGBL for OS or COPY IJLFGBL 
for DOS, which action ensures that each macro has access 
to all global variables. 

The nesting concept is divided into levels as follows: 


1. The outer FD macro instructions call the INO1, INO2, 
INO3, INO4, INOS, INO6, INO7, INO8, INO9, IN10, and 
IN11 (the IN macros) inner macros. 

2. The IN macros call the MSG, the MSG1, the MSG2, the 
MSG3, the TR, and the ASM inner macros as they are 
needed. 

3. The MSG, MSG1, MSG2, and MSG3 macros issue 
MNOTE diagnostic messages and exit. 

4. The outer FD macros may also call the ASM, the MSG, 
MSG1, MSG2, or MSG3 inner macros. This hierarchy is 
further illustrated in Figures 2-7 through 2-11, inclusive. 


The outer FD macros contain promotable operands plus 
the operands that are unique to each one of the macros. 
For example, the FDFORM macro has the FID=, 
MRGSTOP=, MESSAGE=, HTAB=, PACKING=, 
DEVICES=, and BUFFERS= operands. The operands in 
the IN inner macros are positional rather than keyword as 
in the outer macros. The outer macro statements perform 
their own sequence checking to determine whether the 
outer macros are in the correct sequence. Each keyword 
operand in the outer macros is mapped onto a positional 
operand in one of the IN inner macros. This mapping 
begins with the operands that appear most frequently in 
the outer macros and progresses to the operand that is 
specified the least number of times. 

The outer FD macros call one or more of the IN inner 


statements specified by the 3735 forms encoder. The func- 
tions of the outer macros are augmented by seventeen inner 
macros, macro statements called by the outer macros or by 
the inner macros. The inner macros consist of the IDFINO1, 
IDFINO2, IDFINO3, IDFINO4, IDFINOS, IDFIN06, 
IDFINO7, IDFINO8, IDFINO9, IDFIN10, IDFIN11, IDFTR, 
IDFASM, IDFMSG, IDFMSG1, IDFMSG2, and IDFMSG3 


macros to set up the mapping of all the operands that the 
forms encoder specified in the outer macros. The IN inner 
macros perform the mapping process until all the outer FD 
macro operands are placed in global variables (arrays). If 
there is an error, the IN macros call the MSG, MSG1, MSG2, 
or MSG3 inner macro to generate MNOTE messages. 
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Figure 2-7. Hierarchy of FDFORM Macro Calls 
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Figure 2-8. Hierarchy of FDPAGE and FDLINE Macro Calls 
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Figure 2-9. Hierarchy of FDFIELD Macro Calls (Part 1 of 2) 
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Figure 2-9. Hierarchy of FDFIELD Macro Calls (Part 2 of 2) 
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Figure 2-10. Hierarchy of FDEND Macro Calls 
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Figure 2-11. Hierarchy of FDCTRL Macro Calls 
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The TR inner macro is invoked to translate to internal 
3735 code the character strings that the forms encoder spec- 
ified in his outer FD macro statements. If there are errors 
during the assembly processing, the MSG, MSG1 , MSG2, or 
MSG3 inner macro issues MNOTE messages. 

Figures 2-7 through 2-11 illustrate the hierarchy of the 
outer and inner macros according to their macro call struc- 
ture. Figure 2-12 shows the logical flow of the inner macro 
processing according to the order in which the processing 
OCCcUIS. 

The line transmission code of the 3735 terminal is either 
an EBCDIC subset or an ASCII subset. The FD macro 
assembly arranges character data that is part of a form 
description into unpacked and padded internal 3735 codes. 
The resulting even-numbered bytes have a X*40’ high-order 
pad, and the odd-numbered bytes have a X‘70’ high-order 
pad. An example of this code transformation is as follows. 

EBCDIC Codes —3 3735 Internal Codes ——3 Final Data 

C123’ 

or —} X'313233' — X'437143724373' 

X‘'F1F2F3’ 


FD MACRO FUNCTIONS 


FDFORM Macro Instruction 


The FDFORM macro checks that the previous macro did 
not start chaining and that the previous macro, if any, was 
an FDEND statement. Refer to Figure 2-13 for a summary 
of the FDFORM macro functions. 

The FDFORM macro must have a symbolic name, which 
is comprised of from 1 to 8 valid alphanumeric characters, 
with the first alphabetic. This name is used as the catalog 
name by which the operating system and the system pro- 
grammer refer to the form being described. The name 
should begin with an alphabetic character and may not 
contain any blanks or special characters. The assembler 
considers $, #, and @ to be alphabetic characters. 

Each FDFORM macro initializes global arrays (variables). 
These arrays provide for the temporary storage of data that 
pertains to unresolved forward references, for the recording 
of structural level and assembly mode (form or nonform), 
and for the downward transmission of the values of pro- 
motable operands specified in the FDFORM and the other 
structural macros. 

The FDFORM macro arranges the three-digit FID oper- 
and as a group of six bytes with high-order padding added. 
This format makes possible nontransparent transmission to 
the 3735 terminal without regard to the original content of 
the data. The macro generates the bytes indicating the 
PACKING specification for the form and processes the 
MRGSTOP, DEVICES, and BUFFERS operands. The 
assembly also arranges the characters in the MESSAGE 
operand into a group if the user so specifies in the FDFORM 
macro. 


If the user specifies horizontal tabular stops, the assem- 
bly generates a X°7F’ delimiter and the tabular stop inter- 
vals. Finally, the assembly of the FD macros generates a 
X‘00’ delimiter as an end-of-heading indicator. For addi- 
tional information about the format of the assembled code, 
refer to the discussion of the Form Description Programs 
that follows in Part 2, Section 3. 

The inner macros called by the FDFORM macro process 
the HEIGHT, VMRG, WIDTH, HMRG, SOURCE, 
SELFCHK, KIND, SINK, FILL, JUSTIFY, and UL 
operands. 


FDPAGE Macro Instruction 


The structural FDPAGE macro marks the beginning of each 
page description within the current form description. Refer 
to Figure 2-14 for a summary of the FDPAGE macro func- 
tions. 

The FDPAGE macro checks that the previous macro did 
not start chaining and whether FDPAGE is coded within a 
form. The inner macros called by the FDPAGE macro pro- 
cess the SAVELOC, HEIGHT, VMRG, page number, 
WIDTH, HMRG, SOURCE, SELFCHK, KIND, SINK, FILL, 
JUSTIFY, and UL operands. 


FDLINE Macro Instruction 


The structural FDLINE macro indicates the beginning of 
each line description within the current page description. 
Refer to Figure 2-15 for a summary of the FDLINE macro 
functions. 

The FDLINE macro checks that the previous macro did 
not start chaining and whether the FDLINE macro is coded 
within a page. FDLINE calls the inner macros to process 
the SAVELOC, WIDTH, HMRG, and line number operands. 

If the CYCLE operand is specified, the FDLINE macro 
assembles the bytes to transfer control to the start of the 
cycle, a begin-cycle delimiter, and a cycle count. The macro 
reserves space for the index count (index to the target line) 
and for the address of the target field contro! descriptor 
that gives directions for the processing of a data field or the 
performance of a control operation. The CYCLE operand 
creates two unresolved forward references. 

The FDLINE macro also processes the SOURCE, 
SELFCHK, KIND, SINK, FILL, JUSTIFY, and UL oper- 
ands by calling inner macros. 


FDFIELD Macro Instruction 


A structural FDFIELD macro is required for each field 
within the current line description. Refer to Figure 2-16 
for asummary of the FDFIELD macro functions. 

The FDFIELD macro checks that the previous macro did 
not start chaining (unless it was an FDFIELD macro) and 
whether the FDFIELD is coded within a line. The macro 
calls inner macros to process the SAVELOC, CYCLE, and 
field boundary operands. 
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Figure 2-12. Overview of the IN Inner Macros (Part 1 of 2) 
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Figure 2-12. Overview of the IN Inner Macros (Part 2 of 2) 
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Macro Instruction a, ASSCMD) I i> Function 


FDFORM 


Name SS ED 


PACKING > 


Required operand that names the 


FD program stored in the user’s 
data set. 


ls Identifies the FD program for the 
3735 operator. 
MRGSTOP SE > 
Indi f 
MESSAGE E> a message fOr tne 3799 
eee Specifies the horizontal tabular 


Indicates the type of condensation 


Specifies the mechanical left 
margin setting. 


for data sent from the 3735 to the 
central computer. 


a SE Specifies the use of certain buffers 

BUFFERS for additional data storage. 
Specifies Katakana character code 

DEVICES —————— > for IBM Japan terminals. 


Page keywords (see FDPAGE) 


Line keywords (see FDLINE) 


Field keywords (see FDFIELD) 


Figure 2-13. Summary of Assembled FDFORM Macro Functions 


The assembly of control sequences produces mechanical 
motion from the previous output-element position to the 
position of the first output character. If the current macro 
resolves one or more forward references, the macro builds 
an inward-branch table to funnel the branches into the 
start of the field control descriptor (FCD). 

Each branch table entry contains the disk address of the 
target field, in sectors and bytes, relative to the end of the 
entry. The resolution of each forward reference, at assem- 
bly time, alters the location counter (and the control sec- 
tion, if necessary) to point to the null code at which the 
reference was made. This null code is then modified to an 
address pointing to the associated table entry, which in 
turn points to the current FCD. 

The FDFIELD macro calls inner macros to process and 
generate FCDs from the BATCH, SOURCE, COUNT, 


SELFCHK, KIND, SINK, FILL, JUSTIFY, UL, COMPARE, 
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CTR, and IND operands. The inner macros set tables (global 
variables) to allow assembly of control sequences to the 
next FCD. 


FDCTRL Macro Instruction 


The procedural macro FDCTRL regulates terminal opera- 
tions that are not uniquely associated with the processing 
of data within a specific document field. Refer to Fig- 

ure 2-17 for a summary of the FDCTRL macro functions. 

The macro checks whether any chaining originated from 
a previous FDCTRL macro and if FDCTRL is coded within 
a form. 

If the SAVELOC operand is specified, FDCTRL saves 
the location of the current macro within the form descrip- 
tion for backward reference to it (reference is to the name 
coded on the FDCTRL macro). 


Macro Instruction => Assembly a aa Function 


FDPAGE 


Name a a IEE SEES DD Optionally names the page. 

Page Number TT Specifies the number of the page. 
Specifies the vertical output space 

HEIGHT a ae for the page (number of lines per page). 
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Line keywords (see FDLINE) 


Field keywords (see FDFIELD) 


Figure 2-14. Summary of Assembled FDPAGE Macro Functions 


If the CYCLE operand is specified, FDCTRL assembles 
the byte to transfer control to the start of the cycle, a begin- 
cycle delimiter, and a cycle count. 

The IF operand causes assembly of a conditional execu- 
tion sequence consisting of one or more indicator tests and 
an unresolved forward reference. The unresolved forward 
reference is resolved after FDCTRL assembles the last byte 
resulting from the other operands coded in that FDCTRL 
statement. The reference serves to bypass the actions of 
the other operands if the indicator test fails. 

The IND operand assembles code required to set, reset, 
or invert one or more program logic indicators. 

The CTR operand assembles one FCD for each arith- 
metic operation to be performed on one or more counters. 
Each of these FCDs has the following properties: CTR 
operand of FDFIELD, digit character-string source, and 
null sink. 

If the TOTAL operand is specified, the FDCTRL macro 
sets bits in an FD program to cause the 3735 to add to the 
specified counters the values of numeric data fields. Spe- 
cified FD programs process these fields (form IDs are coded 
in the TOTAL operand) and flag them as belonging to par- 
ticular data batches within the FD programs. If both 
TOTAL and COMMAND operands are specified on the 
same FDCTRL macro, the macro does the processing for 
the TOTAL operand before that for the COMMAND 
operand. 

The COMMAND operand assembles (in the sequence in 
which the suboperands are coded) the terminal control com- 
mands that affect the reader and the reader buffer, the 
punch, the punch buffer, the line adapter, the line printer 


buffer, the line printer, the inquiry (INQ) buffer, the stor- 
age (STG) buffer, and the operator identification card 
reader. In addition, this operand assembles the command 
to stop processing the current form and to advance to the 
next copy of the form, if any. 

If the GOTO operand is specified in the FDCTRL macro, 
the macro enters the specified destination in the list of unre- 
solved forward references. The GOTO operand assembles 
null code that is to be filled in later when the destination 
of the GOTO specification is resolved when SAVELOC is 
specified for the destination, in which case the motion is 
immediately generated. 

Finally, the FDCTRL macro sets up tables (global vari- 
ables) to allow the assembly of control sequences to the 
next FCD or FDCTRL macro. 


FDEND Macro Instruction 


The delimiting macro FDEND indicates the end of each 
form description. The macro must be specified once as the 
last macro of each group of FD macros that collectively 
describe a single form. The FDEND macro confirms that 
no source statements have been lost, completes code gen- 
eration, and reinitializes the global variables of the FD 
macros in anticipation of a possible form description to 
follow. Refer to Figure 2-17 for the FDEND macro 
function. 

If any forward references are outstanding, FDEND 
either resolves them or issues an MNOTE message with a 
severity code of eight if they cannot be resolved. 


Logic Of The Form Description Macro Instructions 2-23 


Macro Instruction a w Assembly ST Function 
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Figure 2-15. Summary of Assembled FDLINE Macro Functions 


At the end of each path, the termination process for the 
FDEND macro prints out a list of messages describing the 
resources used, the resources that are incorrectly used, and 
the warning conditions that have occurred in the assembly. 
Each of these MNOTE messages has a severity code of zero. 

The FDEND statement assembles sufficient control se- 
quences to advance the forms to the page 1, line 1, column 1 
position of the next form. If continuous forms are not 
used, FDEND ejects the current form from the printer. 

The FDEND macro supplies the end-processing indicator 
X‘7E’ by generating the unpacked sequence X°477E’. If 
this sequence does not fill out the current KUPB, the macro 
generates an additional pad of X*476E’ to complete the 
block. When the form program records are compressed 
on the disk, the 3735 terminal discards the pad characters. 


THE ASSEMBLY OF FORM DESCRIPTION PROGRAMS 


The assembly of Form Description programs is logically 
divided into four main portions: assembly of the FD pro- 
gram header, address resolution and motion control assem- 
bly, assembly of immediate bytes, and assembly of the 
FCD. FD program header assembly takes place during the 
processing of the FDFORM macro statement (or statements 
if the MESSAGE and/or HTAB operands are chained). Ad- 
dress resolution and motion control assembly occurs just 
before the immediate bytes are assembled. The immediate 


byte assembly is done before assembling the FCDs. The 
assembly of an FCD begins after the testing of the pro- 
motable operands in the FDFIELD macro statements and 
continues with the testing of the operands that are not 
promotable. The exception, when the BATCH operand is 
specified, is that BATCH is always assembled first gen- 
erating an immediate command. An FCD is also assem- 
bled during the processing of an FDCTRL macro state- 
ment when the operands require the internal generation 
of a data field. Other assemblies performed when needed 
are those for cycle controls and for FD program branch 
codes. 

The FD program assembly proceeds by byte pairs, with 
each IDFASM (OS) or IJLFASM (DOS) inner macro creat- 
ing a two-byte DC statement of the form X*4x7y’, or the 
binary or halfword equivalent. The 3735 terminal repacks 
this DC statement to the form X‘Pxy’, where P is the inter- 
nally generated parity, x is three bits, and y is four bits. 
The IDFASM (OS) or ISLFASM (DOS) inner macro instruc- 
tion (called the ASM inner macro) performs the FD pro- 
gram assembly process except for character strings that are 
normally translated and assembled in the TR inner macro. 


Form Description Program Header Assembly 


The assembly of each FD program begins with the three 
decimal characters of the FID operand on the FDFORM 
macro statement. The assembler translates each character 


Macro Instruction => Assembly ET Function 
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Figure 2-16. Summary of Assembled FDFIELD Macro Functions 
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Macro Instruction > Assembly > — Function 
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E> Tests the states of the 3735 program 
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CTR a A PEI Alters the state of 3735 counters. 
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COMMAND a TET 
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but should be thought of as occurring at a specific point on the form. 


FDEND a TTD 
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single form. 


Figure 2-17. Summary of Assembled FDCTRL and FDEND Macro Functions 


to character pairs in internal 3735 code, and then assem- 
bles each character pair into the FD program header as 

the first three byte pairs in the header. The fourth byte 
pair is assembled from the two bits that indicate the 
PACKING=DELIMIT and PACKING=YES specifications. 
The assembler now places unpacked and filled binary zeros 
in the next four byte pairs of the header. Later the FDEND 
macro will overlay these zeros with the number of lines in 
the forms. 

If the MESSAGE operand is specified on the FDFORM 
macro statement, the TR inner macro translates the char- 
acter string coded in the operand to 3735 code and assem- 
bles that code into message byte pairs in the FD program 
header. 

If the HTAB operand is specified on the FDFORM 
macro statement, the ASM inner macro assembles into the 
header unpacked and filled X‘7F’. This byte is followed 
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by pairs of bytes containing the number of positions that 
separate adjacent horizontal tabular stops. These tabular 
stops are from the horizontal tabulation vector in the 
IDFGBL (OS) or IJLFGBL (DOS) copy book. 

The ASM inner macro, finally, assembles a one-byte 
pair of unpacked and filled binary zero to complete the FD 
program header assembly. Figure 2-19 in Part 2, Section 3 
illustrates the format of the assembled FD program header. 


Address Resolution and Motion Control Assembly 


The FD macros assemble sequences of the following bytes 
to transfer control sequentially or nonsequentially between 
FCDs and immediate bytes and to control the position of 
the Selectric print element. 


1. The ASM inner macro assembles the end control bytes 
of the FCD. 


os 


ASM assembles the Selectric motion immediate byte: 
X‘70’ plus an end control byte, where the end control 
byte indicates the type of Selectric motion to be per- 
formed: space, backspace, tab, line feed, or new line. 


Refer to the Selectric immediate byte discussion in 
Part 2, Section 3 for additional information. 


. ASM assembles the GOTO branching address in the 


format 61 A1A2, where 


61 


AlA2 


indicates a GOTO immediate byte; 

indicate a two-byte address representing the 
relative sector and byte displacements needed 
to reach the destination address. 


Refer to the GOTO immediate byte discussion in 
Part 2, Section 3 for more detailed information. 


immediate Byte Assembly 


After the address and motion control assembly, the assem- 
bly of the immediate command bytes proceeds according to 
the following steps. 


l. 


The ASM inner macro assembles the NOP immediate 

byte to fill unused space. 

ASM assembles the three GOTO immediate bytes, the 

first byte of which causes an unconditional branch to 

the FD program byte indicated by the Al A2 address 

in the following bytes. 

If the IF operand is specified in the FDCTRL macro, 

ASM assembles the conditional GOTO immediate 

bytes. These bytes specify a branching address pro- 

vided an IF indicator specifies such a branch. 

If a CYCLE operand is specified, ASM assembles: 

a. First, the seven begin cycle immediate bytes in the 
form 63LLRRA1A2, where 


LL represents the total number of Selectric 
form lines in the cycle; 

RR represents the total number of cycle 
repetitions; 

A1lA2 _ represent the branch to the target macro. 


b. Second, the repeat cycle immediate byte to signal 
the point at which the cycle repeats. 

c. Finally, the end cycle immediate byte to cause 
the 3735 to index the number of lines remaining 
in the LL subfield and to do a carrier return. 

The ASM inner macro assembles the two index space 

immediate bytes to indicate the number of spaces 

needed for spacing from the margin stop to the first 
column of a new line on a Selectric form entered 
using line-feed motion. 

If the TOTAL operand is specified, ASM assembles 

the seven total batch immediate bytes to scan records 

created by execution of FD programs. 

If the CTR operand in the FDCTRL macro is speci- 

fied, ASM assembles the three clear counter imme- 

diate bytes to clear a specified counter to +0. 


8. 


10. 


ee 


If the IND operand in the FDCTRL macro is speci- 
fied, ASM assembles the three set indicator immediate 
bytes to cause the 3735 to set (=1), reset (=O), or 
invert the specified indicator. 

The ASM inner macro assembles next the two Selec- 
tric command immediate bytes. 

If the COMMAND operand is so specified, ASM 


a 


a. 


ssembles: 

The two clear STG immediate bytes to clear the 
buffer associated with the specified device attached 
to the 3735. 


b. The two inquiry command immediate bytes to 


clear the INQ buffer, to request input to the INQ 
buffer, or to send output to the INQ buffer. 

. The two 5496 command immediate bytes to per- 
form operations on the 5496 buffer. 


d. The two or four 3286-3 line printer command 


immediate bytes to perform operations on the line 
printer buffer and on the 3286-3, itself. 

. The two operator ID reader command immediate 
bytes to perform operations on the IDR and CCR 
buffer. 


If the COMMAND operand is specified, ASM assem- 
bles: 


a 


. The cancel form immediate byte to cause the 3735 
to cancel forms. 


b. The end form immediate byte to cause the 3735 to 


end the form, creating a record of its execution in 
the CPU data directory. 


Field Control Descriptor Assembly 


After the address resolution and motion control assembly, 
the assembly of the FCD proceeds according to the follow- 
ing steps. 


Ly 


For FDFIELD macro statements with the BATCH 
operand specified, the ASM inner macro assembles 
into the FCD the batch group, which consists of 
operation code bytes X*6700’ that are unpacked and 
filled. A byte pair derived from the batch number 
completes the batch group bytes. 

The ASM inner macro assembles the data source 

group according to the following conditions: 

a. If the data source is not the keyboard, the ASM 
macro assembles a source-code byte pair from the 
value obtained by concatenating the value B*101’ 
and four bits of the data source global variable. 

b. If FID, RSN, or ‘string’ is specified, the ASM 
macro does not assemble a second part. 

c. If the source is CTR, the ASM inner macro assem- 
bles the counter number as a single arithmetic- 
value byte pair. 

d. If the source is a buffer, ASM assembles the 
starting-character location as two arithmetic-value 
byte pairs. 
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Note: The outer FD macro saves the location of the 
first source type code byte to be used for future 
reference. 


The ASM inner macro assembles the data-type byte 

pair, which contains: 

a. Katakana, alphabetic, or numeric data-type bits 
from the data source global variable; 

b. Transmit-as-entered and print-as-entered flag bits; 

c. Validity flag bit; 

d. Function flag bit. 

Except for the following conditions, the byte pair 

uses the data source global bits as they are: 

a. If SOURCE=“‘string’ is specified, the assembly 
forces KIND=U (no testing) to be indicated. 

b. If SOURCE=CTR (d), SINK=CTR (d), PICTURE, 
the numeric COMPARE, or IND operands are spe- 
cified, the assembly forces KIND=N to be indi- 
cated. The late discovery of this condition forces 
the reassembly of this byte pair. 

The flag bit settings indicate certain conditions as 

follows: 

a. If SINK=TMT is specified with left justify, blank 
fill, and no PICTURE operand, the transmit-as- 
entered flag is on. 

b. If, in addition to the previous conditions, 
SINK=PRT is specified, the print-as-entered flag 
is on (unless SINK=(PRT,AFTER) is specified). 

c. If SOURCE="string’ is specified, the validity flag 
is off. Otherwise, if NUMPAD, minimum or exact 
count, and COMPARE are specified; OPTIONAL 
is not specified; and SELFCHK is specified not 
NO, the validity flag is on. 

d. The function flag is on to indicate one or more of 
the following: | 
(1) CTRor IND is specified; 

(2) COMPARE operand is chained through more 

than one statement; 

(3) asink other than PRT or TMT is specified; 

(4) editing is specified for PRT or TMT, or 

SINK=(PRT,AFTER). 

The ASM inner macro assembles the character-count 

byte pair, an arithmetic value. The character count 

is determined according to the SOURCE operand as 
follows: FID and RSN indicate three characters and 

CTR (d) indicates ten characters. The string length 

(K‘-2) is used if the SOURCE operand is not chained; 

otherwise, the character count is from the COUNT 

operand that specifies an exact value. 

For SOURCE=KBD, the macro chooses the char- 
acter count by the following priority: first, if the 
exact or maximum COUNT operand is specified, the 
ASM inner macro gets the character count from this 
operand. Second if field lower and upper bounds 
are specified, the inner macro calculates the character 
count indicated in the bounds. Finally, if neither of 


the above are available, the inner macro selects the 
character count from the field lower bound and 
explicit LNG (d) specification. 

The ASM inner macro also assembles the character 
count for buffers from several alternatives according 
to a priority. The following list indicates the choices 
from first to last: 

a. Buffer lower and upper bounds. 

. Buffer explicit LNG (d) operand specification. 
. Exact COUNT operand specification. 

. Field lower and upper bounds. 

. Field explicit LNG (d) operand specification. 

If SOURCE=‘string’ is coded, the TR and ASM 
inner macros translate, unpack, and fill the entire 
string during assembly processing. The string assem- 
bly generates a character count. If the actual count 
does not agree with the preassembled count, the ASM 
macro reassembles the count unless the string is to be 
chained. 

The ASM inner macro assembles the validity byte pair 
only when the validity flag is on in the data-type byte 
pair (see step 3). The first three bits (0-2) represent 
attributes of the SOURCE=KBD operand; the next 
two bits (3 and 4) control the testing of the numbers 
of characters entered and are mutually exclusive; the 
last 2 bits (5 and 6) control the testing of the COM- 
PARE and SELFCHK functions. Bits 0, 1,2, and 6 
are derived from the data source global variable in the 
IDFGBL (OS) or IILFGBL (DOS) copy book. The 
bits and their indications when the validity flag is on 
are as follows: 


omMun St 


Bit Indication 


NUMPAD operand is coded 
AUTOEOF is not coded 

OPTIONAL is not coded 

exact COUNT is coded 

minimum COUNT is coded 
COMPARE operand is coded 
SELFCHK operand is not coded ‘’NO”’ 


Aah WN A O 


The ASM inner macro assembles the function byte 
pair only if the function flag is on in the data-type 
byte pair (see step 3). Flags in the function byte pair 
indicate functions that are to be performed: 

a. Performance of arithmetic operations on counters 
to include one or more clear-and-add sequences as 
needed to provide for the SINK=CTR (d) specifi- 
cation. 

b. Comparison of entered data for setting program 
logic indicators. 

c. Control of either a buffer sink or the PRT or TMT 
sinks with any data format other than left justified 
with blank fill. 

If none of these indicated functions is needed, but the 

function flag is on in the data bytes because the 

COMPARE operand is continued, the ASM inner 


11. 


macro assembles the function byte pair with no flags 
on. The terminal control program treats this func- 
tion byte pair as a no-operation. 


._ The ASM inner macro assembles the minimum 


character-count byte pair from the COUNT operand 

only when the minimum count flag is on in the valid- 

ity byte pair (see step 5). The byte pair represents 
the arithmetic value coded as COUNT=(MIN,n). The 
inner macro does not assemble a value of one for this 
function. 

The ASM inner macro assembles the value-check 

group when the COMPARE operand is specified. This 

group consists of one or more repetitions of the fol- 
lowing sequence: 

a. The ASM macro assembles the value-check control 
byte pair from bits representing a single comparison 
operator as a combination of NOT (optional) with 
LESS, EQUAL, or GREATER (mutually exclusive) 
plus a logical indicator AND or OR if more com- 
parisons follow. 

b. ASM assembles the comparand character count 
byte pair from the value of the number of compa- 
rand characters, less two if the comparand is a 
string, and retains this value for comparison with 
the number of byte pairs actually assembled. 

c. The TR and ASM inner macros process the com- 
parand characters, and, if the resulting count does 
not agree with the assembled count, ASM reassem- 
bles the count. 

The ASM inner macro assembles the self-check byte 

pair (SELFCHK operand) from three bits of the data 

source global variable. 

If a sink of CTR (d) or the CTR operand is specified, 

the ASM inner macro assembles the arithmetic group. 

A sink of CTR (d) causes the assembly of a byte pair 

made up of flag bits for clear and add operations, 

followed by a byte pair containing the value of the 
counter number. 

If both SINK=CTR (d) and the CTR operand are 
specified, the flag byte pair for sink is produced first 
with a chaining flag on. 

If only the CTR operand is specified, the operand 
causes the assembly of one or more double byte pairs 
like those just described, except that the clear indi- 
cator is never on. The flags indicate one of the mu- 
tually exclusive operations add (ADD), subtract 
(SUB), multiply (MPY), divide (DIV), or divide and 
round (DVR). 

The ASM inner macro assembles the compare group 

consisting of one or more subgroups, one for each 

indicator specified in the IND operand. Each sub- 
group comprises the following pieces: 

a. The comparison operator byte pair—assembled 
from flags for the relational operators LT, EQ, and 
GT with (optional) NOT, plus one flag bit for the 


1:2. 


mutually exclusive connectives AND or OR if they 
are specified. The last comparison operator byte 
pair of each subgroup except the last has a chaining 
flag on. 

b. The comparand character count byte pair—derived 
from the number of characters in a comparand, 
exclusive of any framing apostrophes. The assem- 
bled byte pair contains a tentative value that is to 
be checked later for validity. 

c. The comparand character byte pairs—processed by 
the TR and ASM inner macros from the specified 
comparand. If the resulting actual count differs 
from the tentative count assembled (see b. above), 
ASM reassembles the count. 

If a buffered sink is specified, or if the PRT or TMT 

operands are coded with editing specified other than 

left justified with trailing blanks, the ASM macro 
assembles the data sink group. If assembled, the 
group consists of one to five subgroups, one for each 
sink specified, with the subgroups for PRT and TMT 
being the last one or two assembled if they are re- 
quired. The assembly of each subgroup is as follows: 

a. The ASM inner macro assembles from bits in the 
data sink global variable the sink-type byte pair, 
which includes a chaining flag derived from the OR 
of a scratch copy of the usability flags of data sink 
global. The assembly of each sink subgroup causes 
a corresponding scratch bit to be turned off, so 
that when the last subgroup is assembled the chain- 
ing flag is off. 

b. ASM assembles the start-by te-O byte pair from the 
data sink global bits combined to call for centering, 
right justification with blank fill or zero fill, or 
PICTURE operand editing, which are all mutually 
exclusive. In addition, if the adjusted sink starting 
position exceeds 127, bit 6 is on. The user- 
specified sink starting position must be changed 
to 0 origin and then incremented by an offset 
of four. 

c. ASM assembles a start-byte-1 byte pair to contain 
the remainder of the starting position after division 
by 128. 

d. ASM assembles the number of sink characters into 
the next byte pair unless the PICTURE specifica- 
tion is used. For PICTURE, the assembled byte 
pair contains a tentative count equal to the num- 
ber of picture characters exclusive of framing apos- 
trophes. The TR and ASM inner macros process 
the PICTURE string assembling the picture char- 
acters and a delimiting X“7F’ character, accumu- 
lating a count of the digit and insertion characters 
in the picture string. If this accumulated count 
does not equal the previously assembled count, 
ASM reassembles the count. 
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There are some assembly modifications for the PRT and 
TMT operands. The start-byte quadruplet is replaced by a 
control-byte byte pair that is similar to the start-byte-0 
byte pair except that bit 4 is the UL indicator. Bit 5 is the 
PRT indicator and bit 6 is the TMT indicator. The UL and 
TMT specifications are mutually exclusive, as are the PRT 
and TMT operands. 

The method for deriving the buffer sink character count 
is the same as that for buffer sources. No sink count is re- 
quired for the CTR(d), PRT, or TMT specifications. Refer 
to step 4 for the explanation of the buffer source character 
count. 

For detailed descriptions of the internal bytes that com- 
prise the FD programs, proceed to the Form Description 
Program Organization section that follows. 


FORM DESCRIPTION PROGRAMS 


The Form Description macros translate user-encoded 
options into FD programs that become input to the FD 
utility. A user-written program consists of an FDFORM 
macro, other FD macros, and an FDEND macro. Similarly, 
the generated FD program consists of an FD program head- 
er, immediate bytes and field control descriptors (FCDs), 
and an FD program trailer. Refer to Figure 2-18 for an 
illustration of the FD program structure. 

The IDFASM or IJLFASM (called ASM) inner macro 
assembles generated FD programs for input to the FD 
utility. The following discussion abstracts the generated 
FD programs from their frames of keyed unpacked pro- 
gram blocks (KUPBs), which ASM generates, and con- 
centrates on the generation of bytes that the 3735 terminal 
can interpret. 


FD Program Header 


An FD program header consists of the following fields: 
form ID, data format byte, lines form—printer, lines 
form—Selectric, operator message, tabs, and begin byte. 


FD Program immediate Bytes 
Header FCDs 


Figure 2-18. The FD Program Structure 


Form ID PACKING Lines 
Form - 
(1) (2) Printer 

(3) 

oe 
Tabs Begin 
Byte 
(6) 


Figure 2-19. The FD Program Header 


Section 3. Form Description Program Organization 


Figure 2-19 illustrates the format of the FD program 
header. The following list explains each field in the FD 
program header. 


1. The FID operand routine of the FDFORM outer macro 
generates the form ID field. The first three bytes of an 
FD program header must contain a three digit identifier 
(FID) used to select the FD program. The ID represents 
the number by which the 3735 operator may select an 
FD program. The IDs must be in internal 3735 code and 
may be between 000 and 989, inclusive. The IDs of 990 
through 998 are reserved for IBM supplied resident FD 
programs, and ID 999 is for the functional test form. If 
one of these special IDs is transmitted to the 3735 from 
the CPU, it is accepted by the terminal control program. 
However, if one of the special IDs is selected by the 3735 
operator, the 3735 performs the special function indi- 
cated not the user program. 

2. The PACKING operand routine of the FDFORM outer 
macro generates the data format byte (also called the 
packing field). The data format byte specifies the format 
of field data (collected under FCD control) transmitted 
by the 3735. The bit significant data format is as 
follows: 


FD Program 
Trailer 


SSS 


Lines MESSAGE 
Form - 
Selectric (5) 


(4) 
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a. Blank fill (bit O=0, bit 1=0): indicates that variable 
length fields are to be padded with blanks to the 
right of the last character entered. For example, 
the 3735 transmits a seven character field as ABCbbbb 
if only three characters are entered, or as ABCDEFG 
if all seven characters are entered. 

b. Packed with delimiter (bit O=1, bit 1=0) strip trailing 
blanks: indicates that the 3735 transmits all fields 
with a delimiter following the last character entered. 
For example, the 3735 transmits a seven character 
field as ABC* (with * representing the X‘1C’ file 
separator character) if only three characters are en- 
tered, or as ABCDEFG* if all seven characters are 
entered. 

c. Packed with no delimiter (bit O=0, bit 1=1): indicates 
that the 3735 transmits all fields without trailing 
blanks or a delimiter. For example, the terminal 
transmits a seven character field as ABC if only three 
characters are entered, or as ABCDEFG if all seven 
characters are entered. 


. The FDFORM macro generates the two-byte lines form— 


printer field (in binary) with an initial value of zero. The 
FDEND macro overlays the zero value with the correct 
value of the number of lines in the form. This field is 
required, whether the 3286-3 printer is attached or not. 


. The FDFORM macro generates the two-byte lines form— 


Selectric field (in binary) with an initial value of zero. 
The FDEND macro overlays the zero value with the cor- 
rect value when it does its processing. The two lines 
form—Selectric bytes specify a count of the total num- 
ber of lines from the beginning of a Selectric application 
to the beginning of the same application on the next 
sequential form. The 3735 terminal control program 
decrements this count by one for each new line or line 
feed operation it performs. The terminal control pro- 
gram uses the resulting count as an index to the start of 
the next form whenever it ends or cancels a record. The 
terminal control program does not decrement a zero 
count, but does a carrier return to the left hand margin 
at the beginning of the target form. 


Note: The operator message is not included in the lines 
form—Selectric byte count. 


. The MESSAGE operand routine of the INO1 inner macro 


generates the operator message field in character data. 
An optional operator message may be included in the FD 
program to inform the 3735 operator of form usage, set- 
up procedure, and so forth. The terminal operator may 
bypass the message printout if he desires. 

The terminal control program requires that type ele- 
ment positional control characters be imbedded within 
the message if such positioning is needed. Tabs should 
not be used because the terminal control program sets 
tabs after it prints the message. The terminal control 
program issues a carrier return before it begins printing 
and a carrier return just after the printout. 


The length of the message is not restricted. The ter- 
minal control program requires a message delimiter: 

a X‘7F’ if tab information follows, or a X‘O0’ if there 
are not tab definitions. Message characters must be in 
internal 3735 code. The 3735 operator can retrieve the 
message only on the Selectric® I/O II device. 

6. The HTAB operand routine of the INO1 inner macro 
generates the horizontal tabulation intervals (tabs) field 
beginning with the delimiter X‘7F’. The terminal con- 
trol program forces the type element to the left margin 
stop and spaces the print ball tO times before stopping 
it. The 3735 operator then sets the tab and depresses 
the OPER key to continue. The terminal control pro- 
gram continues this procedure until it finds a X‘00’ 
delimiter. The t’s represent binary numbers with deci- 
mal values between 1 and 127, inclusive. 

The 3735 operator can bypass the tab setting pro- 
cedure by depressing the ENTER key. The terminal 
control program does not restrict the number of tab 
stops. However, there cannot be tab stops at character 
positions greater than 128 without at least one stop at 
a character position less than 129. 

The FD program does not use a tab operation to ad- 
vance to a field whose first print position is adjacent to 
the last printed position of the preceding field. The 
Selectric device does not recognize a tab stop at char- 
acter position one. 

7. The begin byte generator routine of the INO1 inner 
macro generates the begin byte. The begin byte con- 
tains a X‘00’ and marks the beginning of the bytes that 
exercise control over the data entered on the 3735. 
The terminal operator can begin FCD control by per- 
forming one of the following sequences. 


@ The operator selects an FD program by entering an 
ID. 


@ The operator presses one of the following: 

a. OPER — The operator receives an operator message 
and begins the tab setting procedure. When the tab 
stops are set, FCD control begins. 

b. TAB — The operator does not receive an operator 
message and begins the tab setting procedure. 
When the tab stops are set, FCD control begins. 

c. ENTER — The operator bypasses both the operator 
message and the tab setting procedure. FCD con- 
trol begins immediately. 


Immediate Bytes and Field Control Descriptors 


The second part of an FD program consists of sequences of 
immediate bytes or field control descriptors (hereafter 
called FCDs), or both. Each FCD consists of a variable 
number of bytes, the function of each byte is defined by 
its format and its position within the FCD. Defining a 
document field requires a minimum of three bytes: a data- 
type byte, a character-count byte, and an end control byte. 
The data-type byte defines the initial data checking require- 
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Figure 2-20. NOP, GOTO, and Conditional GOTO Immediate Bytes 


ments. The character-count byte provides a binary number 
equal to the maximum number of characters that can be 
entered into the field. The end control byte provides for 
the movement of the Selectric carrier or platen to position 
the type element. 

In the absence of an explicit specification, the 3735 
terminal control program assumes that input data originates 
from the Selectric® I/O II keyboard. The FD macro pro- 
gramming support assumes the same default source. Ifa 
different source is used, the FCD must contain a data source 
byte to indicate the source. 

Immediate command bytes are interspersed with FCDs to 
provide functions not directly related to the control of data 
being entered into a field. The immediate bytes may indi- 
cate an instruction which is to be completed immediately, 
or may indicate the location of the next byte to be exam- 
ined by the terminal control program. 

The FDPAGE, FDLINE, FDFIELD, FDCTRL, and 
FDEND macros generate these portions of an FD program. 


| Byte (Indicator Number) 


The following describes the structure of the immediate 
bytes and of the FCDs. 


Immediate Bytes 


Immediate bytes cause the 3735 terminal to control devices 
to branch within an FD program, or to change the contents 
of internal storage areas. Each immediate byte field is ex- 
plained in the following list. 


1. The NOP immediate byte contains a 3735 no- 
Operation code, generated to hold space in the assem- 
bled data. This byte has no effect on program execu- 
tion. Refer to Figure 2-20 for the NOP byte format. 

2. The end control routine (in INO3) or the GOTO oper- 
and routine (in IN10) creates the three GOTO imme- 
diate bytes. The first byte causes an unconditional 
branch to the FD program byte that is indicated by 
the displacement in the two bytes that follow, Al 
and A2. The GOTO immediate bytes provide for an 


? 


Logic Of The Form Description Macro Instructions 2-33 


2-34 


unconditional logic branch to another part of the FD 
program. The Al and A2 address bytes represent the 
relative sector and byte displacements needed to reach 
the destination address. The byte displacements (rela- 
tive to the A2 address byte location plus one) is calcu- 
lated by multiplying the binary number SSSSS by 234 
and adding the binary number A2ZA2A2A2A2A2A2 
to the result. Refer to Figure 2-20 for an illustration 
of the GOTO immediate bytes. 
The IF operand routine (in IN10) generates the condi- 
tional GOTO immediate bytes. These bytes cause the 
3735 to branch to the location indicated in the Al 
and A2 bytes if a specified indicator combination 
indicates the branch. The GOTO on condition (or 
conditional GOTO) immediate bytes provide condi- 
tional logic branching to another part of the FD pro- 
gram. The conditions for branching are based on the 
set/reset state of one or more indicators (10 — In). 

If the specified indicator combination is evaluated 
to a logical one, the GOTO branch target is to the 
Al A2 address. If the combination is evaluated to 
zero, the terminal control program examines the FCDs 
following the Al A2 address bytes. The combination 
may be expressed in the form I0 = 0/1 [AND/OR 
[1=0/1 ... AND/OR In = 0/1]. The result of the logi- 
cal expression is as if the AND functions are evaluated 
first. For example, F=I1 or I2 AND I3 OR [4 is eval- 
uated as F=I1 OR (12 AND I3) ORI4. The AND/OR 
functions are specified by setting the corresponding 
bit in the condition byte. The last condition byte 
cannot have an AND/OR bit set on. The indicator 
value to be tested for is specified in the value bit. The 
indicator number is specified in the indicator byte; the 
low order four bits specify one of the 16 indicator 
bytes, and high order three bits specify the bit within 
the byte. The byte number can range from X‘0’ to 
X°F’, inclusive, and the bit number can range from 
X‘0’ to X°6’, inclusive, yielding a total of 112 indi- 
cators. 

The 3735 indicators fall into three types: general 
purpose, special, and feature indicators. 
a. General purpose indicators: 

Indicators with an I-byte from X‘00’ to X‘6B’, 
inclusive, have unrestricted usage. The user may 
set, reset, or invert each or all of these 84 indica- 
tors. The indicator ALL functions refer to these 
84 general purpose indicators. The 3735 terminal 
control program resets these indicators to zero at 
the beginning of each FD program execution. 

b. Special indicators: 

The seven indicators of I-byte X‘OC’ are read- 
only indicators. The user may not set, reset, or 
invert these indicators. The 3735 terminal control 
program resets these indicators at the beginning of 
each FD program and sets them whenever the set- 


ting condition occurs. The seven indicators are as 
follows: 


Bit QO Indicates playback mode. The terminal 
control program resets this indicator 
for all modes except playback. 

Bit 1 Indicates 5496 end of card file. The 
terminal control program sets this bit 
when a /* is read from the 5496 card 
reader-punch and resets this indicator 
for all other device read operations. 

Bit 2 Indicates inquiry timeout. The termi- 
nal control program sets this bit when 
an inquiry send command has not been 
completed successfully and resets this 
indicator whenever a send command is 
initiated. 

Bit3 Reserved. 

Bit4 Reserved. 

BitS Not used. 

Bit6 Not used. 


c. Feature indicators: 


Each group of seveni dicators with an I-byte 
from X‘OD’ to X‘6F’, inclusive, are read-only indi- 
cators representing the featured attachments that 
are supported for the 3735 terminal. The indica- 
tors are as follows: 


Indicator X‘OD’ Indicates an attached 5496 

Indicator X‘1D’ Indicates an attached 3286-3 

Indicator X‘2D’ Indicates an attached operator 
identification reader 

Indicator X*3D’ Reserved 

Indicator X‘4D’—X‘6F’ Not used 


During enter-form mode, the terminal control pro- 
gram stores a delimiter on disk to indicate whether 
or not a conditional GOTO branch has been taken. 
The terminal control program tests indicators X*00’ 
to X°6B’, inclusive, during playback or error-correct 
mode to determine whether a branch was taken in 
enter-form mode. If contrary branching occurs, 
the terminal control program issues an operator 
message (invalid data path) and exits to local mode. 
Tests on indicators X‘OC’ to X‘6F’, inclusive, result 
in the same data path as taken in enter-form mode 
whether or not the new test results in a different 
branch/no branch condition. Refer to Figure 2-20 
for an illustration of the conditional GOTO imme- 
diate bytes. 


4. The begin cycle (CYCLE operand part 2) routine (in 


INO3) generates the seven begin-cycle immediate bytes 


initially in the form X‘63’, 8X°60’. After assembly, 
these bytes finally appear in the form 
63 LL RR Al1A2. 


a. The LL bytes represent the total Selectric form 
lines encompassed in the cycle. The end summary 
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Figure 2-21. The Begin, Repeat, and End Cycle Immediate Bytes 


routine (CYCLE operand part 5) in the INO1 inner 
macro updates these two bytes. 

b. The RR bytes represent the total number of cycle 
repetitions. 

c. The Al1A2 bytes represent the branch to the next 
FCD bytes to be examined. The cycle limit 
(CYCLE operand part 3) routine (in IN11) updates 
these bytes. Refer to Figure 2-21 for the formats 
of the cycle bytes. 

5. The cycle limit (CYCLE operand part 3) routine cre- 
ates the repeat cycle immediate byte to signal the 
point at which the cycle repeats. Each time a repeat 
cycle command is encountered, the terminal control 
program decrements the number of repeats by one 
and transfers control to the first FCD byte following 
the A2 byte. The control program ends the cycle 
when the number of repeats is zero. 

6. The cycle limit (CYCLE operand part 3) routine cre- 
ates the end cycle immediate byte. This byte causes 
the 3735 to index the number of lines remaining from 
the LL subfield and to do a carrier return. The 3735 
decrements the count of the number of lines for each 
Selectric printer line passed over. Following the car- 
rier return, the terminal control program examines 
the immediately following FCD byte. 

Note: The begin cycle, repeat cycle, and end cycle 

immediate bytes are generated in that order. The FCDs 

and immediate bytes between the begin cycle and repeat 
cycle immediate bytes correspond to the macros between 
the start-of-cycle macro and the limit macro, inclusive. 

The FCDs and immediate bytes between the repeat cycle 

and the end cycle immediate bytes correspond to the 

macros comprising a summary block. 

7. The end control routine generates the two index space 
immediate bytes. The value of the byte n is a binary 
count of the number of spaces from the left margin 
stop to the first field of a new line on the Selectric 
form that has been entered using line feed motion 
(without carrier return). The 3735 terminal control 
program uses this immediate command in error cor- 
rection. The index space function should follow the 
last line feed end control or Selectric command. 
Refer to Figure 2-22 for an illustration of the index 
space bytes. 


& 


10. 


11. 


12. 


13. 


14, 


0 
= 
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Repeat End 
Cycle Cycle 
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The TOTAL operand routine (in INO9) generates the 
seven total batch immediate bytes. The bytes cause 
the terminal control program to scan the records cre- 
ated by execution of the FD program whose identifier 
is given by the subfield FFF. The batch subgroup 
identifies the FCDs in the FD program as belonging 
to the same batch as the B subfield of the total batch 
immediate bytes. These FCDs create data that is 
accumulated in the counter given by the counter 
subfield of the total batch immediate bytes. The 
terminal control program does not clear the counter 
before the data is accumulated. Refer to Figure 2-22 
for the format of the total batch bytes. 

The COMMAND operand routine (in IN10) generates 
the cancel form immediate byte that causes the ter- 
minal control program to cancel the form. Refer to 
Figure 2-23 for the cancel form immediate byte 
format. 

The COMMAND operand routine generates the end 
form immediate byte. This byte causes the terminal 
control program to end the form, creating a record 
of its execution in the CPU data directory. Refer to 
Figure 2-23 for the format of the end form imme- 
diate byte. 

The FDCTRL CTR operand routine (in INO9) creates 
the three clear counter immediate bytes to cause the 
terminal control program to clear the specified 
counter to +O. Refer to Figure 2-23 for the format 
of the clear counter bytes. 

The FDCTRL IND operand routine (in INO9) gen- 
erates the three set indicator immediate bytes to 
cause the terminal control program to set (=1), 

reset (=O), or invert the specified indicator. Refer 

to Figure 2-23 for the format of the set indicator 
bytes. 

The end control routine generates the two Selectric 
command immediate bytes. These bytes provide for 
the immediate movement of the Selectric carrier and 
platen. Refer to Figure 2-24 for the format of these 
immediate bytes. 

The COMMAND operand routine generates the two 
clear STG immediate bytes to cause the terminal con- 
trol program to clear the buffer. The storage buffer 
(STG) is a 236-byte buffer that is resident on the 
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3735 disk. At the beginning of each FD program, gram restores the buffer to the state it was at the 


the terminal control program saves the contents of beginning of the record. Refer to Figure 2-25 for 
this buffer. If a record is canceled, the control pro- the format of the CLEAR STG buffer bytes. 
0 1 0 1 2 6 
Tete, See. 18 
—— —~/ 
Index Space Total Batch 
(7) (8) 


B-1 Byte Batch Number (Binary) 
FFF - 3 Bytes of Form !D (Internal 3735 Code) 
C - 1 Byte of Counter Number (Binary) 


Figure 2-22. The Index Space and Total Batch Immediate Bytes 
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Figure 2-23. The Cancel Form, End Form, Clear Counter, and Set Indicator Immediate Bytes 
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Figure 2-24. The Selectric Command Immediate Bytes 
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IS. 


16. 


17. 


18. 


The COMMAND operand routine generates the two 
inquiry command immediate bytes to cause the ter- 
minal control program to clear the inquiry buffer, 
transmit the inquiry buffer, or discontinue the line. 
The inquiry buffer is a 236-byte buffer unit that is 
resident on the 3735 disk. The terminal control pro- 
gram does not save the contents of this buffer at the 
beginning of each record. Neither does the terminal 
control program restore the buffer when the operator 
enters error-correct mode. Refer to Figure 2-25 for 
the format of these bytes. 

The COMMAND operand routine generates the two 
5496 command immediate bytes to cause the terminal 
control program to clear the 5496 buffer, request in- 
put from the 5496, or send output to the 5496. The 
5496 buffer is a 192-byte buffer that resides on the 
3735 disk. The terminal control program does not 
save the contents of this buffer at the beginning of 
each record. Neither does the control program re- 
store the contents of this buffer when the operator 
enters error-correct mode. Refer to Figure 2-26 for 
the formats of the 5496 commands. 

The COMMAND operand routine generates the two or 
four line printer command immediate bytes to cause 
the terminal control program to clear the line printer 
buffer, skip lines on the line printer, or send output to 
the lirie printer. Refer to Figure 2-27 for the formats 
of the line printer command immediate bytes. 

The COMMAND operand routine generates the two 
operator ID reader command immediate bytes to 
clear the IDR and CCR buffer, to read the IDR buf- 
fer, or to read the CCR buffer. Refer to Figure 2-28 
for the formats of the IDR and CCR command imme- 
diate bytes. 


The following summarizes each immediate byte field, 
indicating the length of each field and the format. 


Type 
1. 
2. 
3. 


10. 
11. 


Length Format (Hex) 
NOP Immediate Byte 1 60 
GOTO Immediate Bytes 3 61A1A2 
Conditional GOTO 
Immediate Variable 62 «<6 
Begin Cycle Immediate 
Bytes 7 63LLRRA1A2 
Repeat Cycle Immediate 
Byte 1 64 
End Cycle Immediate Byte 1 65 
Index Space Immediate 
Bytes 2 66n 
Total Batch Immediate 
Bytes 7 6701 BFFFctr 
Cancel Form Immediate 
Byte 1 68 
End Form Immediate Byte 1 69 
Clear Counter Immediate 
Bytes 3 6A00ctr 


12. 


13. 


14. 


15. 


16. 


17. 


18. 


Set Indicator Immediate 


Bytes 3 6Aindctrl 
Selectric Command 

Immediate Bytes 2 70ec 
Clear STG 

Immediate Bytes 2 7140 
Inquiry Command 

Immediate Bytes 2 72inqctrl 
5496 Command 

Immediate Bytes 2 73ctrl 
Line Printer 

Command immed. 2or4 741pctrinn 
IDR and CCR 

Command Immed. 2 75ctrl 


Refer to Figures 2-20 through 2-28 for diagrams of each of 
these immediate bytes. 


Field Control Descriptors 


FCDs correspond to FDFIELD or to FDCTRL macros and 
cause 3735 operations involving data input, manipulation, 
and output. An FCD generated each time an FDFIELD 
macro is coded consists of up to ten fields. Each of these 
fields is explained in the following list. Refer to Figure 2-29 
for an illustration of the FCD structure. 


lg 


The batch group is an optional immediate field gen- 
erated by the BATCH operand routine. 

The data source group is present for all FCDs except 
those corresponding to FDFIELD macros with 
SOURCE=KBD coded. The data source group gen- 
erator routine (in INO4) generates the data source 
group from internal tables (global variables). 

If a field is numeric (the numeric bit is on in the 
data-type byte), the data source field can have a lead- 
ing plus or minus sign. Also, for a numeric field, the 
low order position of the field can have an overpunch 
to represent a negative number. The terminal control 
program strips off the overpunch for printing but re- 
tains the overpunch for storing right-justified in buf- 
fered sinks or on disk for transmission. 

A negative source field can have a leading plus or 
minus sign and be right justified with leading blanks 
in the source field. As the terminal control program 
reads the source field, it strips off the leading blanks. 
If the print bit is on in the data-type byte, the termi- 
nal control program prints these leading blanks. The 
terminal control program makes any further reference 
to the field (arithmetic, compare, data sink, and so 
forth) with a character count equal to the source char- 
acter count minus the leading blanks. Data source 
input characters are comprised only of the characters 
from X‘20’ to X‘7E’ in the internal 3735 code, or a 
cent sign, a plus-or-minus sign, or a logical-not sign. 
Any violation of requested validity checking (char- 
acter type, length, range, self check) results in an 
operator error message indicating a data source error. 
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Figure 2-25. The Clear STG and Inquiry Command Immediate Bytes 
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Figure 2-26. The 5496 Command Immediate Bytes 
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Figure 2-27. The 3286 Line Printer Command Immediate Bytes 
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Figure 2-28. The IDR and CCR Command Immediate Bytes 
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Figure 2-29. The FCD Structure 


Within the data source group are nine commands 
to indicate functions that are to be performed. These 
commands indicate the following sources for input 
data: FD program ID, record number, emitted data, 
counters, storage buffer (STG), inquiry buffer (INQ), 
5496 buffer, the 3286-3 buffer, and the IDR/CCR 
buffer. Refer to Figure 2-30 for the format of each 
of these source data function specifications. 

a. The FD program ID command causes the terminal 
control program to use the FD program identifica- 
tion number (FID) of the active FD program as the 
input data source. The ID character count must be 
three. The terminal control program pads zeros to 
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the left of significant digits. The control program 
does not store the FD program number on disk 
unless the transmit bit is on in the data-type byte. 


. The record number command causes the terminal 


control program to use the record number assigned 
to the active record as an input data source. The 
character count must be three and zeros are padded 
to the left of significant digits. The terminal con- 
trol program does not store the record number on 
disk unless the transmit bit is on in the data-type 
byte. 


. The emitted data command causes the terminal 


control program to use the FCD bytes immediately 


Data Source Byte 


Type Count 
ae | Forownio 
a [reer eer mera 
SOURCE=FD Program ID 
ae | eiwaon 
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Data Char 
Es Storage Buffer 
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Cntr Data Char 
Nmbr Type Count ) 


SOURCE=Counter 


Start Start 
Byte Byte 


SOURCE=Storage 


Start Start Data Char 
Byte Byte Type Count 
SOURCE=Inquiry 
Start Start Data Char 
Byte Byte Type Count 
SOURCE=5496 Buffer 
‘57’ Start Start Data Char 
Byte Byte Type Count 
SOURCE=3286-3 Buffer 


Start Start Data Char | 
Byte Byte Type Count 


SOURCE = IDR Buffer 
SOURCE = CCR Buffer 
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Figure 2-30. The Data Source Group 
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following the character count as the input data 
source. If validity and/or function bytes are de- 
sired, they must follow the emitted data. The ter- 
minal control program does not store emitted data 
on disk unless the transmit bit is on in the data- 
type byte. 


. The counters command causes the terminal control 


program to use the counter specified by the count- 
er address as the input data source. The character 
count must be ten. There are 21 ten-digit signed 
counters, the addresses of which are binary num- 
bers between X‘00’ and X‘14’, inclusive. At the 
beginning of each FD program the terminal control 
program saves the contents of the counters. Ifa 
record is canceled, the control program restores the 
counters to their state at the beginning of the rec- 
ord. If the operator enters error-correct mode, the 
terminal control program restores the counters to 
their values at the beginning of the line. The con- 
trol program does not save the counters on disk 
unless the transmit bit is on in the data-type byte. 
The counters are always ten digits long. If a count- 
er is negative, the units position has an overpunch. 
The terminal control program takes source data 
from the counters in all operating modes. 


. The storage command causes the terminal control 


program to use the number of bytes specified in 
the character count, starting at the specified start- 
byte location in the storage buffer, as the input 
data source. The start-byte location is a two-byte 
binary number from four to 239, inclusive. The 
terminal control program always stores the source 
data in the storage buffer on disk. The control pro- 


binary number from four to 195, inclusive. The 
terminal control program always stores the source 
data from the 5496 buffer on disk. The control 
program takes the source data from the 5496 buf- 
fer during enter-form mode and from the disk (data 
stored during enter-form mode or supplied as CPU 
data) during error-correct and playback modes. 


. The 3286-3 buffer command causes the terminal 


control program to use the number of bytes speci- 
fied in the character count, starting at the specified 
start-byte location in the 3286-3 buffer, as the in- 
put data source. The start-byte location is a two- 
byte binary number from four to 239, inclusive. 
The terminal control program always stores the 
source data from the 3286-3 buffer on disk. The 
control program takes the source data from the 
3286-3 buffer during enter-form mode and from 
the disk (data stored during enter-form mode or 
supplied as CPU data) during error-correct and 
playback modes. 


i. The IDR or CCR command causes the terminal 


control program to use the number of bytes speci- 
fied in the character count, starting at the specified 
start-byte location in the IDR or CCR buffer, as 
the input data source. The start-byte location is a 
two-byte binary number from 196 to 239, inclu- 
sive. The terminal control program always stores 
the source data in the IDR or CCR buffer on disk. 
The control program takes the source data from 
the IDR or CCR buffer during enter-form mode 
and from the disk (data stored during enter-form 
mode or supplied as CPU data) during error-correct 
and playback modes. 


gram takes the source data from the storage buffer 
in enter-form mode and error-correct mode and 
from the disk (data stored in enter-form mode or 
supplied as CPU data) during playback mode. 

f. The inquiry command causes the terminal control 
program to use the number of bytes specified in 
the character count, starting at the specified start- 
byte location in the inquiry buffer, as the input 
data source. The start-byte location is a two-byte 
binary number from four to 239, inclusive. The 
terminal control program always stores the source 
data in the inquiry buffer on disk. The control 
program takes the source data from the inquiry 
buffer in enter-form mode and from the disk (data 
stored during enter-form mode or supplied as CPU 
data) during error-correct or playback mode. 

g. The 5496 buffer command causes the terminal con- 
trol program to use the number of bytes specified 
in the character count, starting at the specified 
start-byte location in the 5496 buffer, as the input 
data source. The start-byte location is a two-byte 


3. The data-type field (one byte) is a required field for all 
FCDs. The data-type byte generator routine (in INO6) 
creates this byte from internal tables (global variables). 
Other routines may update the data-type byte because 
the value of this byte is subject to change after its initial 
generation. 

The data-type byte is present for all input/output 
fields and specifies the following: 
@ the field character type 


@ whether or not the field is to be printed as entered 


@® whether or not the raw input data is to be trans- 
mitted to the 3735 


@ whether or not any additional validity and/or func- 
tion bytes follow 
Within the data-type byte are combinations of bit 
settings that indicate the following character checking 
functions: 
a. No character check (bit 0=0, bit 1=0, bit 2=0): 
indicates that any and all characters are accepted 
at the 3735. 
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. Katakana code (bit 0=1,bit1=0,bit 2=0): indi- 


cates that kana characters and space only will be 
accepted at the 3735. 


. Alphabetic character check (bit O=0, bit 1=1, 


bit 2=0): indicates that only A through Z (upper 
and lower case) or space are accepted at the 3735. 


. Numeric character check (bit O=0, bit 1=0, bit 


2=1): indicates that only 0 through 9 and an op- 
tional leading sign are accepted at the 3735. The 
leading sign may be either plus or minus and must 
be the first keyed character in the field. 


. Alphameric character check (bit 0=0, bit1=1, 


bit 2=1): indicates that only A through Z (upper 
and lower case), 0 through 9, or space are accepted 
at the 3735. The terminal control program rejects 
a leading sign. 


. Transmit function: indicates that the terminal con- 


trol program flags the input data for the associated 
field for unedited transmission to the CPU if this 
bit is on. 


. Print Selectric function: indicates that the terminal 


control program prints the associated input field 
while it is being entered if this bit is on. When the 
bit is off and the field is to be printed, look for a 
Selectric data sink byte to follow to perform that 
function. 


. Validity check: indicates that the terminal control 


program performs additional checks on the input 
data if this bit ison. A validity byte that imme- 
diately follows the character-count byte defines 
the additional checks. 
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Figure 2-31. The Data-Type Byte 


i. Function check: indicates that the terminal con- 
trol program specifies the presence of a function 
byte to control arithmetic, compare, and data sink 
functions if this bit is on. The function byte imme- 
diately follows the character-count byte or, if one 
is present, the validity byte. 

Refer to Figure 2-31 for an illustration of these bit 

settings. 

The character-count byte is a required field for all 

FCDs. The character count generator routine (in 

INO6) creates this byte from internal tables (global 

variables) and other routines may update the byte 

since the value of it may not be known at the time 
of its initial generation. 

The character-count byte contains a binary number 
equal to the exact or maximum number of characters 
that can be entered into a field. The maximum num- 
ber of characters that can define a field is 127. 

The character count of a numeric field includes an 
optional leading sign. The character count of a self- 
check field includes the self-check digit. The char- 
acter count of a field that is to have the self-check 
digit generated does not include the self-check digit. 
Once the digit has been generated, any compare or 
data sink function should assume that the field con- 
tains the additional digit. 

The emitted data group is an optional field and is 

present for all FCDs corresponding to FDFIELD 

macros coded with SOURCE=‘string’. The emitted 
data group generator routine (in INO6) creates this 
field. 


Data Type 


Function 


Byte 


Min Value Self Arith Comp Data 
Count Bytes Chk Bytes Bytes Sink 


Function 
Group 
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The validity byte is an optional field generated by the 
validity byte generator routine in the INO6 inner 
macro. The validity byte is present if the validity bit 
(bit 5) in the data-type byte is on. The validity checks 
are not mutually exclusive. These checks control the 
number of characters entered into a field and the con- 
tent of the data. The validity byte indicates seven 
conditions: numeric (key) pad enable, enter required, 
mandatory field, fixed length field, minimum char- 
acter count in a field, numeric/alphabetic value check, 
and checking of a self-check number. 

The numeric-pad-enable bit enables the ten-key 
pad. If this bit is off, or if the validity byte is not 
present, the terminal control program interprets the 
keypad character in the normal way. Enabling the 
keypad changes the keypad characters to their nu- 
meric values. If a field is to be checked for numeric 
characters and the keypad is enabled, the 3735 accepts 
the ten-key pad and the regular numeric characters. 
Because some alphabetic characters are not usable in 
the numeric check, this bit should be turned on when 
using numeric pad. 

The enter-required bit indicates that the operator 
must press the ENTER key or the TAB key to exit 
from the field. 

The mandatory-field bit indicates that the operator 
must enter at least one character into the field. If this 
bit is off and no characters are entered at the 3735, 
the terminal does not perform the validity checks 
specified. If the operator tries to bypass the manda- 
tory field, the terminal control program turns on the 
error indicator. 

The fixed-length bit indicates that if an entry is 
made, the operator must enter the exact number of 
characters specified in the character-count byte. If 
this condition is violated, the terminal control pro- 
gram turns on this length indicator. 

The minimum-count bit, assuming that no function 
byte is present in the FCD, indicates that the imme- 
diately following byte contains a binary number. This 
number is equal to the minimum number of characters 
that can be entered into the field, if an entry is made, 
before the operator can advance to the next field. 

The minimum-count byte is not present for a mini- 
mum of one character. 

The value-check bit indicates that a check is to be 
made on the numeric and/or alphabetic value of a 
field. Refer to paragraph 8 for an explanation of the 
value-check byte. 

The self-check bit indicates that a check is to be 
made of a self-checking number or that a self-check 
digit is to be generated. Refer to paragraph 8 for an 
explanation of the self-check byte. Refer to Fig- 
ures 2-32 and 2-33 for illustrations of the validity 
byte and of the validity group. 


The function byte is an optional field generated by 
the function byte generator routine in the INO6 inner 
macro. This byte is present if the function bit (bit 6) 
in the data-type byte is turned on. The function byte 
indicates the presence of these functions: arithmetic, 
compare, and data sink functions. 

The arithmetic-function bit indicates an operation 
to be done onacounter. The field data operates on 
counter X and the results are stored in counter X. 
Refer to paragraph 9 for an explanation of the arith- 
metic byte in the function group. 

The compare-function bit indicates compare bytes 
are present in the function group. Refer to paragraph 
9 for an explanation of the compare bytes. 

The data-sink bit indicates that data sinks are pres- 
ent in the function group. Refer to paragraph 9 for 
an explanation of the data sink bytes. 

Refer to Figures 2-32 and 2-34 for illustrations of 
the function byte and the function group. 

The validity group is an optional field and is present 
only when bits 4, 5, and 6 in the validity byte (see 
paragraph 6) indicate its presence. 


Bit4on minimum count field is present. 
Bit5 on value bytes are present. 
Bit6on _ self-check field is present. 


The value-check byte provides the ability to check 
the numeric or alphabetic value of a field. Refer to 
the conditional GOTO immediate byte explanation 
for the use of the AND/OR bits in the value-check 
byte. The greater than, equal to, and less than bits in 
the value-check byte are mutually exclusive. The 
NUMB CHAR byte represents the number of char- 
acters in the comparand. 

For numeric comparisons the (numeric bit is on in 
the data-type byte), the comparand may contain a 
leading plus or minus sign. The terminal control pro- 
gram compares the field to the comparand as a signed 
numeric value and pads the shorter length number 
with leading zeros for the comparison. 

For alphabetic or alphameric character string com- 
parisons (the numeric bit in the data-type byte is off), 
the terminal control program pads the shorter string 
with trailing blanks for the comparison. 

The value-check comparand characters are in inter- 
nal machine code. The 3735 does not restrict the 
number of AND/OR functions. A 3735 with ASCII 
code uses the ASCII collating sequence; a 3735 with 
EBCDIC code uses the EBCDIC code collating se- 
quence. 

The comparand-character-count byte for numeric 
comparisons should include a leading sign if one is 
present in the comparand. Signed comparands may 
have a leading sign. The absence of a leading sign 
implies a positive number. The terminal control pro- 
gram uses any non-numeric character in a comparand 
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Figure 2-32. The Validity and Function Bytes 
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Figure 2-33. The Validity Group 
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Figure 2-34. The Function Group (Part 1 of 3) 
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value checked against a numeric field in the compare 
operation and assumes a value representative of the 
machine collating sequence. 

The terminal control program automatically can- 
cels any field that the operator enters and that fails to 
pass the value check. When the operator presses the 
OPER key to turn off the Range Check light, the ter- 
minal control program cancels the field. 

The self-check byte provides a check of a self: 
checking number or the generation of a self-check 
digit. If the generate bit (bit 0) is off, the 3735 
checks the field using the specified modulus routine 
(modulo 10 or 11). If the operator enters the field 
and the self-check test fails, the 3735 turns on the 
Self-Check light and locks the keyboard. The termi- 
nal control program automatically cancels the field 
when the operator presses the OPER key. 


Arith Cntr 
Cntrl No 


When the generate bit is on, the 3735 generates the 
self-check digit and appends it to the input data. Re- 
fer to Figure 2-32 for an illustration of the validity 
byte and to Figure 2-33 for illustrations of the valid- 
ity group. 

The function group is an optional field and is present 
only when the bits in the function byte (see para- 
graph 7) indicate its presence. Bits 0, 1, and 2 in the 
function byte indicate that the function group con- 
tains the following bytes: 


BitOon arithmetic bytes are present 
Bit 1 on compare bytes are present 
Bit 2on data sink bytes are present 


The arithmetic byte indicates that field data operates 
on counter X and the results are stored in counter X. 
The add, subtract, multiply, divide, and divide-and- 

round bits are mutually exclusive. The clear bit may 
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Figure 2-34. The Function Group (Part 2 of 3) 


be on with another arithmetic function. If a counter If bit O is on, the 3735 clears the specified counter to 
is ever set to zero as the result of an arithmetic func- plus zero. The counter number is X*00’ to X*14’. The 
tion, it is a plus zero. The terminal control program clear bit may be on with one other function; however, 
performs arithmetic functions in all operation modes. the terminal performs the clear operation first. 
Refer to Figure 2-34 for an explanation of the arith- If bit 1 is on, the 3735 adds the field to the counter 
metic bytes. and stores the result in the counter specified. 
Within this byte reside seven indicators: If bit 2 is on, the 3735 subtracts the field from the 
BitO —_ indicates a clear operation counter and stores the result in the counter. 
Bit 1 —_— indicates an add operation If bit 3 is on, the 3735 multiplies the counter by 
Bit 2 —_ indicates a subtract operation the field and stores the result in the counter. 
Bit3 indicates a multiply operation If bit 4 is on, the 3735 divides the counter by the 
Bit 4 indicates a divide and truncate operation field and stores the result in the counter. The 3735 
BitS —_ indicates a divide and round operation disregards any remainder. If an attempt is made to 
Bit6 —_ indicates chaining to another arithmetic divide by zero, the 3735 clears the counter to plus 
operation zero. 
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If bit 5 is on, the 3735 divides the counter by the 
field and stores the result in the counter. The termi- 
nal uses any remainder to half-adjust the quotient. If 
an attempt is made to divide by zero, the 3735 clears 
the counter to plus zero. 

If bit 6 is on, the 3735 looks for another arithmetic 
control byte and continues performing arithmetic 
functions. 

The compare bytes provide the ability to check the 
numeric or alphabetic value of a field. Refer to the 
conditional GOTO immediate explanation for the use 
of the AND/OR bits in the compare bytes. The com- 
pare bytes use the results of the comparisons to set or 
reset an indicator. If the results of the compare logi- 
cal function is true, the 3735 sets the specified indi- 
cator. If the expression is false, the terminal resets 
the indicator. The terminal control program executes 
the compare function in all operation modes. 

Within a compare byte reside seven indicators: 


BitO indicates a less than comparison 

Bit 1 —_ indicates an equal comparison 

Bit 2. _—_ indicates a greater than comparison 

Bit 3 —_— indicates a not qualification of bits 0, 1, 
or 2 

Bit4 — indicates a compare chain 

Bit5 indicates an and logic operation 

Bit 6 — indicates an or logic operation 


If the compare-chain bit is on, the 3735 uses the logi- 
cal expression evaluated to this point to set or reset 
the indicator specified in the byte following the last 
comparand byte for that segment of the chain. Once 
the indicator is set or reset, the 3735 treats the fol- 
lowing compare function as if it were the only com- 
pare function. 

The 3735 uses the data sink bytes to store data in 
the buffered sinks and to control printing and/or edit- 
ing. The terminal performs the data sink functions in 
the order they are encountered and uses the sink chain 
bit (bit 0) to indicate additional data sink functions. 

If the sink count or picture digit count for numeric 
fields (the numeric bit is on in the data-type byte) is 
less than the number of digits to be placed in the sink, 
the 3735 uses the low-order digits of the source. Re- 
fer to Figure 2-34 for detailed illustrations of the data 
sink bytes. 

For all buffer sinks, the data sink byte has several 
fields following it: the starting-byte location in the 
buffer in which the resultant data is to be stored, the 
size of the sink field (maximum of 127), and optional 
picture bytes. The high-order four bits of the starting- 
byte location specify left justify, right justify with 
leading blanks, right justify with leading zeros, center, 
or edit. These functions are mutually exclusive. The 
3735 stores no data on disk (as a part of the created 


record) for the buffered sink functions. The terminal 
stores only into the 5496 buffer during playback 
mode. 

The 3735 does the left-justify function when all 
sink function bits are off in the start-byte-zero byte. 
The terminal stores the input field in the buffer left 
justified. If the sink count is greater than the source 
count (character count), the 3735 pads the buffer 
field with trailing blanks. If the input field is numeric 
(the numeric bit is on in the data-type byte) and con- 
tains a negative sign overpunch in the low-order-digit 
position, the 3735 transfers the overpunched digit to 
the sink field if the overpunched digit is stored in the 
rightmost sink field character position. 

For centering, the 3735 centers the input source 
field into the sink field. If any odd character is to be 
to the right of the raw data, the terminal should see 
the right-blank bit in the start-byte-zero byte. The 
center function centers the input field into the sink. 
The 3735 considers any blanks in the data as charac- 
ters in the field to be centered. If the input field is 
numeric and contains a negative sign overpunch in the 
low-order-digit position, the 3735 transfers the over- 
punched digit to the sink field if, and only if, the over- 
punch is stored in the rightmost sink field character 
position. 

For right-justify with leading blank, the 3735 right 
justifies the input source field with leading blanks and 
stores the field in the sink field. The terminal replaces 
any leading zeros in the source field with leading 
blanks. If the input field is numeric and contains a 
negative sign overpunch in the low-order-digit posi- 
tion, the 3735 stores the overpunch in the rightmost 
sink field character position. 

For right-justify with leading zero, the 3735 right 
justifies the input source field with leading zeros and 
stores it in the sink field. The terminal replaces any 
leading blanks in the source field with leading zeros. 
If the input field is numeric and contains a negative 
sign overpunch, the 3735 stores the overpunch digit 
in the rightmost sink field character position. 

For the edit function, the picture digit count re- 
places the sink count byte. This count is equal to 
the number of picture bytes that have associated digit 
positions. This count equals the sum of 9s and zero 
suppression characters in the picture stream. All pic- 
ture bytes are represented by 3735 internal codes 
with the following exceptions: 


@ The blank insertion byte should be a X‘20’; 


@ The radix symbol is used for stopping zero sup- 
pression only, and should be an uppercase V if no 
suppression characters follow, or a lowercase v if 
suppression characters do follow. 
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The 3735 must initiate a drifting sequence with two 
contiguous drifting characters. 

The only way to display the source field sign is to 
use the picture bytes S, +, or -. Otherwise, the 3735 
drops any overpunched digit and assumes any leading 
sign is a leading zero. 

The Selectric sink function controls the printing 
and or storing for transmission of edited data. For 
explanation of the right justify, left justify, center, 
and edit functions, refer to the description of the 
buffered sinks. 

The Selectric data sink functions are as follows: 


@ Underline: if the underline and print bits are on, 
the 3735 underlines the field. If the right blank 
bit is on, the terminal only underlines significant 
(nonblank) characters. If the center bit is on, the 
3735 underlines only characters that are centered. 
If the left justify bit is on (other bits are off), the 
3735 does not underline trailing blanks. If the 
edit function is used, the 3735 underlines the re- 
sults of the picture stream. 


@ Print Selectric: The requested function is to send 
output to the Selectric device. 


@® Transmit: The 3735 stores the edited data on disk 
for transmission to the CPU. 


The end control byte, generated by the end control 
routine in the INO3 inner macro, is a required field. 
The 3735 spaces the Selectric print element to the 
end of the field before executing the end control 
functions of space, backspace, or line feed. The ter- 
minal control program executes horizontal tabbing 
and new line functions without spacing to the end of 
the field. If tabs are set within a variable length field 
that is not mandatory, code an end control byte of 


End Control Byte 


Function 


Backspace 


Horizontal Tab 


New Line 
Reserved 
Reserved 


Reserved 


X‘00’ followed by an immediate tab command. Even 

if the print bit in the data-type byte is turned off, the 

3735 always executes the end control function. Refer 
to Figure 2-35 for a summary of the end control byte 

functions. 


Refer to Figure 2-29 for a summary of the FCD structure 
and to Figures 2-30 through 2-35 for detailed diagrams of 
each FCD field. 


FD Program Trailer 


An FD program trailer consists of an end form byte, an FD 
program delimiter, and, optionally, padding to complete a 
sector (KUPB). The FDEND macro generates these bytes 
when the user codes an FDEND macro in his source deck. 
Refer to Figure 2-36 to see the format of the trailer. 


FD Program Maintenance 


This section describes some of the problems that may occur 
at some time in the generation of a form processing system. 
The trouble-shooting information presented in the fol- 
lowing paragraphs may be further augmented by referring to 
the diagnostic messages and MNOTE messages contained in 
Part 4, Appendix C of this book and to the sample program 

in Part 4, Appendix D. 


Trouble Shooting 


Troubles may occur anywhere during the building and gen- 
erating of a system for processing forms. Difficulties may 
appear at macro assembly time, utility processing time, 
during the transmission of data to the 3735, and during the 
execution of FD programs. The following discussions ex- 
plain some of the conditions that may occur and describe 
steps to be taken to correct these situations. 


Space (0000000 indicates space out to end of field before doing next motion- 
end control noop) 


Line Feed (0110000 indicates carrier return) 
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The Form Description (FD) utility is a service program that 

prepares unpacked Form Description programs for transmis- 
sion to one or more IBM 3735 Programmable Buffered Ter- 

minals. The program may be executed under either the 


Operating System (OS) or the Disk Operating System (DOS). 


FD UTILITY PURPOSE AND FUNCTION 


The FD utility is the IBM support program that prepares 
the Form Description unpacked programs for transmission 
to the 3735 terminals. The utility operates basically the 
same under OS and DOS. It reads the output of the Form 
Description macro assembly from a card reader or an equiv- 
alent sequential input device. It checks the input programs’ 
integrity and arranges the programs into 476-byte blocks. 
The utility then writes the arranged program blocks into a 
user-Specified data set that is later made available to a user- 
written application program. 

The aims of the FD utility are accomplished through the 
logical organization of the program in three sequential job 
steps: Control step, Linkage Editor step, and Storage step. 

The Control step verifies the correctness of the object 
module input (except that data generated in columns 17-72 
of the TXT card images) and generates the necessary Link- 
age Editor control statements for the next step. 

The Linkage Editor step performs the linkage editing of 
the input object module, under control of the control state- 
ments generated in the first step. The Linkage Editor step 
also includes the object module IDFST (under OS) or 
IJLFST (under DOS) in the input. This module then 
becomes the root segment of the overlay program executed 
in the Storage step. 

The third and last step, the Storage step, is the execution 
of the linkage edited overlay program. The data originally 
generated by the macro assembly is brought into main stor- 
age as overlay segments and put out to the user’s private 
data set in 476-byte blocks. Additionally, an optional JCL 
parameter (OS) or control cards (DOS) may be used to 
allow the storage of Form Description programs whose 
names are the same as those of programs already existing in 
the user’s data set. 


SYSTEM REQUIREMENTS 


The main storage required by the FD utility is that required 
for the minimum OS or DOS Linkage Editor available to the 
system. The main storage required by the utility, exclusive 
of the Linkage Editor step, is no more than 10K bytes (OS) 
or 12K bytes (DOS). The utility requires the presence of 
three I/O devices: a card reader or equivalent device, a 
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printer, and a direct access storage device. The utility uses 
no more than 10 tracks of 2311 storage, or the equivalent, 
for program residence. The user’s auxiliary storage require- 
ments depend on the number and size of the forms being 
described. 

To include the FD utility in his operating system, the 
user must copy it from the component library on which it 
is distributed. This function may require the allocation of 
additional space. Before the FD utility is executed, the 
system programmer must ensure that suitable input and 
output data sets are designated through correct coding of 
the job control statements. 


PHYSICAL CHARACTERISTICS OF THE FD UTILITY 


Characteristics for OS Systems 


The FD utility program contains three modules: IDFCT, 
IDFST, and IDFMO1. These modules may reside in either a 
private (user) job/step library or the system link library 
(SYS1.LINKLIB). The module IDFCT is executed in the 
first, or Control, step. The module IDFST is executed in 
the third, or Storage, step. However, it must be linkage 
edited with the output of the first step before it can be 
executed as the GO module. The linkage editing is per- 
formed during the second, or Linkage Editor, step of the 
utility. The linkage editing is necessary because IDFST is 
the root segment of an overlay program whose overlay seg- 
ments are available only at the end of the first step. The 
message module, IDFMO1, contains the messages that are 
written out during the execution of the first and third steps. 
These messages may be written to either the system printer 
or a system console. 

The module that is loaded and executed in the third step, 
that is, IDFST and the linkage edited overlay segments, is an 
overlay program. Its function is to write the data that is 
contained in the overlay segments into the user’s partitioned 
data set. After the module has been executed, it serves no 
further purpose. Therefore, it should be regarded as a 
temporary data set and should be deleted at the end of the 
third step. 


Characteristics for DOS Systems 


The FD utility program contains five relocatable modules: 
IJLFCT, IJLFST, IJLFLOAD, IJLFUPDT, and IJLFMO1. 
IJLFCT and IJLFMO1 reside in a core image library; 
IJLFST, IJLFLOAD, and IJLFUPDT may reside in either 

a private (user) relocatable library or the system relocatable 
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library. The module IJLFCT, which is executed in the first, 
or Control, step, must be linkage edited during system gen- 
eration. The modules IJLFST, IJLFLOAD, and IJLFUPDT 
are executed in the third, or Storage, step. However, they 
must be linkage edited with the output of the first step be- 
fore they can be executed. This linkage editing is performed 
during the second, or Linkage Editor, step of the utility. 
The linkage editing is necessary because IJLFST is the root 
phase of an overlay program whose overlay phases are avail- 
able only at the end of the first step; IJLFST loads either 
IJLFLOAD or IJLFUPDT to process these overlay phases. 
The message module, IJLFMO1, contains the messages that 
are written out to the system printer during the execution 
of the first and third steps. IJLFMO1 contains no re- 
locatable code; it must be linkage edited during system 
generation to allow its subsequent loading by IJLFCT, 
IJLFLOAD, and IJLFUPDT. 

The modules that are loaded and executed in the third 
step, that is, IILFST, IJLFLOAD, IJLFUPDT, and the link- 
age edited overlay segments, comprise an overlay program. 
The function of this overlay program is to write the data 
that is contained in its overlay phases into the user’s indexed 
sequential data set. Since there are no external inputs to 
this module, it is a temporary data set and is effectively 
deleted at the end of the third step. The Linkage Editor 
step places this temporary data set in the unused core image 
library space, but does not catalog it. The user must ensure 
that this library space is adequate. 


OPERATIONAL CONSIDERATIONS 


The FD utility is scheduled through the job input stream 
and encompasses three sequential job steps, as previously 
discussed. There is one optional feature: in OS, the 
REPLACE parameter; in DOS, RPLACE control statements. 
These options are discussed fully in Part 3, Section 2, 
“Method of Operation.”’ The FD utility program creates 
one or more executable Form Description unpacked pro- 
grams (FD programs) from the one or more object modules 
that are produced by the assembly of the Form Description 
macros (FD macros). The utility also places the FD pro- 
grams in a user-defined partitioned data set (under OS) or 
indexed sequential data set (under DOS), which serves the 
user aS a library of FD programs. The use of the FD util- 
ity involves the Linkage Editor, since the object modules 
produced by the FD macros contain backward references 
resulting from ORG statements. 

If the utility encounters an uncorrectable error, the 
action it takes depends upon which step of the three step 
sequence is being executed. The action may be either the 
immediate termination of the program or, if the Storage 
step is executing, the deletion of a partially created 
sequence of FD programs from the user’s data set, then 
termination. In both cases, however, a message explaining 
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the action and its cause is written to either the system 
printer or the system console. The utility produces a diag- 
nostic listing at the end of each program step. The listing 
produced by the last step includes the name of every FD 
program that was added to, deleted from, or not added to 
the user’s data set. 

The utility’s response to environmental errors arising 
from improper input, such as a card missing or out of 
sequence, is to write a message to the Control step diagnos- 
tic listing, print the listing, then terminate. Any input fol- 
lowing the erroneous card is not processed. The response to 
job control errors, such as the insufficient allocation of 
space in a data set, is to terminate processing and to note 
the error condition in the diagnostic listing. The response 
to implementation errors, such as errors in system control 
blocks, is those error recovery and termination options pro- 
vided by OS and DOS. 


Input and Output of the FD Utility 


The object modules produced by the FD macros are the 
principal input to the FD utility program. These modules 
were designed to make the input as self-describing as pos- 
sible. That is, the records themselves contain all the infor- 
mation needed for their processing in the three steps of the 
FD utility. The physical organization of these object mod- 
ules is 80-byte card images. Two levels of logical organiza- 
tion exist within the physical organization of the object 
modules. The primary level of logical organization is by 
control section (CSECT); the secondary level is by keyed 
Form Description unpacked program block (KUPB). 
Each CSECT consists of from one to six KUPBs (under OS) 
or from one to three KUPBs (under DOS), plus an end-of- 
assembly indicator that indicates the presence or absence of 
additional CSECTs. Each KUPB is a 486-byte record which 
is comprised of four subfields: name, count, data, and end- 
of-form. The physical descriptions of CS9ECTs and KUPBs 
are contained in Part 3, Section 2, “Method of Operation.” 
The principal output data set of the FD utility is the 
user’s library of FD programs. This library is a partitioned 
data set (under OS) or an indexed sequential data set (under 
DOS) whose members are the individual FD programs. 
These members are known by either the name used in the 
name field of the FDFORM macro or by the temporary 
name that the FD Utility assigns if FD program replacement 
is not specified in the user’s JCL. The output data set is 
described in more detail in the section entitled “Method of 
Operation.” 


OS Control Information 


Execution of the FD utility program is sequential: the 
Control step is executed first; the Linkage Editor step, sec- 
ond; and the GO module (Storage step), third and last. The 
control is mediated through the OS Job, Task, and Data 


Management facilities. In particular, the Job Control facil- 
ities allow the passing of intermediate data sets between job 
steps. Therefore, correctly coded job control statements are 
imperative to the correct functioning of the FD utility 
program. 

Because the control is mediated by OS Job Management, 
the FD utility may be executed one step at a time, or even 
as steps following an assembly of the FD macros. Since 
each step in the program sets a nonzero return code if it 
detects an error condition, cataloged procedures that include 
appropriate COND keyword guards may be designed to suit 
the user’s program integrity requirements. 

The data flow among the program units includes a variety 
of data types: 


e@ The input object module data 
@ The object module IDFST 
@ The overlay segments of the GO module 


The physical descriptions of these data types and a discus- 
sion of the processing performed upon them by the FD 
utility are contained in Part 3, Section 2, “Method of 
Operation.” 


DOS Control Information 


Execution of the FD utility program is sequential: the Con- 
trol step is executed first; the Linkage Editor step, second; 
and the Storage step, third and last. The control is mediated 


through the DOS Job Control and Data Management facili- 
ties. In particular, the Job Control facilities allow the pass- 
ing of intermediate data sets by planned changes of device 
assignments. For example, SYSPCH, an output data set of 
the Control step, becomes (through Job Control interven- 
tion) SYSLNK, an input data set to the Linkage Editor step. 
Therefore, correctly coded job control statements are im- 
perative to the correct functioning of the FD utility. 

Because the control is mediated by the DOS Job Control 
facility, the FD utility may be executed one step at a time 
(one step per job). However, it may also be executed as 
sequential job steps following an assembly of the FD mac- 
ros. In this case, since each step in the program would be 
executed unconditionally, even if errors were encountered 
in previous steps, the user should insert a PAUSE statement 
after each step. He should then allow the next step to pro- 
ceed only after he validates the correctness of the previous 
step. Furthermore, to avoid processing delays, the user 
should perform the FD macro assembly separately from the 
execution of the FD utility. 

The data flow among the program units includes a vari- 
ety of data types: 


e@ The input object module data 
@ The object modules ISLFST, IJLFLOAD, and IJLFUPDT 
@ The overlay segments of the Storage step 


The physical descriptions of these data types and a discus- 
sion of the processing performed upon them by the FD 
utility are contained in Part 3, Section 2, “Method of 
Operation.” 
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FD UTILITY GENERAL OPERATION AND DATA 
DESCRIPTIONS 


General Logical Flow 


The assembly of the FD macros produces one or more card- 
image object modules that contain FD programs. By them- 
selves, these modules are not executable in a 3735 terminal; 
they must be (1) validated, (2) linkage edited, (3) arranged 
into a usable format, and (4) placed in a user-defined FD 
program library. The purpose of the FD utility is to per- 
form these four major tasks. To accomplish this purpose, 
the utility is divided into three sequential job steps: Con- 
trol, Linkage Editor, and Storage. 

The Control step, which is executed first, performs the 
following functions: 


® Validates the input data 
@ Creates Linkage Editor control statements 


@ Writes the validated input data and control statements to 
a utility data set 


@ Writes a diagnostic listing of the Control step results to an 
output data set 


Next, the Linkage Editor step, which is the second job step 
executed, performs four more functions: 


@ Creates the overlay program that is executed in the 
Storage step 


@ Resolves backward origins and, under OS, resolves a V- 
type address constant 


@ Writes the newly created overlay program to a tempo- 
rary library 


@ Writes a diagnostic listing of the Linkage Editor step 
results to an output data set 


Finally, the Storage step, the third job step to be executed, 
performs the following functions: 


@ Loads the overlay segments from the temporary library 
where the Linkage Editor step placed them 


@ Creates new or replacement members (FD programs) and 
stores them in the user’s FD program library 


@® Writes a diagnostic listing of the Storage step results to an 
output data set 


Of the four major tasks mentioned previously, the Control 
step accomplishes the first one; the Linkage Editor step, the 
second; and the Storage step, the last two. Figures 3-1 and 
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3-2 represent the logical flow of the FD utility operating 
under OS and DOS, respectively. 


Input and Output Data Descriptions 


Input Data 


The object modules produced by the FD macros are the 
principal input to the FD utility program. These modules 
were designed to make the input as self-describing as pos- 
sible. That is, the records themselves contain all the 
information needed for their processing in the three steps of 
the FD Utility. The physical organization of these object 
modules is as 80-byte card images. Each module contains 
three record types: ESD, TXT, and END. Figure 3-3 
describes the format of each type. Figure 3-4 is a graphic 
representation of a module’s physical organization. 

Within the physical organization of the object modules, 
there are two levels of logical organization. The primary 
level of logical organization is by control section (CSECT); 
the secondary level is by keyed Form Description unpacked 
program block (KUPB). 

Under OS, each CSECT is (6*486) +4=2920 bytes long, 
except the last one. The last CSECT is (n*486) +4 bytes 
long, where n is an integer with a value of 1, 2,3, 4,5, or 
6. Under DOS, each CSECT is (3 *486) +6=1464 bytes long, 
except the last one. The last CSECT is (n*486) +6 bytes 
long, where n is an integer with a value of 1, 2, or 3. This 
means that a CSECT consists of from one to six or one to 
three KUPBs plus a four-byte or six-byte end-of-assembly 
indicator under OS and DOS, respectively. The end-of- 
assembly indicator is used to indicate the presence or 
absence of additional CSECTs. The indicator is set to all 
zeros for all but the last CSECT, for which it is set to all 
ones. In addition to the length restrictions of CSECTs, 
there are also name restrictions. Under OS, the CSECT 
names are in the sequence IDF1000, IDF1001, IDF1002, 
etc. Under DOS, the CSECT names are in the sequence 
IJLF1000, IJLF1001, IJLF1002, etc. Figures 3-5 and 3-6 
illustrate the composition of OS and DOS CSECTs. 

The secondary level of logical organization within the 
input object modules is by KUPB. Each KUPB consists of 
a 10-byte key field and a 476-byte unpacked program 
block. Within the key field are two subfields: (1) an eight- 
byte name subfield and (2) a two-byte count subfield. 
Within the unpacked program block field are two more sub- 
fields: (3) a 470-byte data subfield and (4) a six-byte end- 
of-form subfield. 
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SYSIN => 


(Assembled object 
module of FD 
macro instructions) 


Control Step: 


e@ Checks input data 
and creates Linkage 


Editor control statements. 


SYSDD 


j= 


Writes output to > 
SYSUT1. 


Writes a diagnostic 
listing of the Control 
step results to SYSPRINT. 


Implementation: 


e User-selected access 
method (BTAM or TCAM) 
program executed to 


transmit stored programs 
to terminals. 


User application programs 
Process data gathered at 
terminals. 


SYSLIB 
(User-defined 
FD program library 


<ofee}]<o 


SYSPRINT | <j7—— 


LINKAGE EDITOR: 


Creates the overlay 
program executed in the 
next step. 


Resolves backward 
origin and V-type address 


references. 


Writes the overlay (GO) 
program out to SYSLMOD 


Writes a diagnostic 
listing of the Linkage 
Editor step results 
out to SYSPRINT. 


‘ 


SYSPRINT 


Storage Step: 


@ Loads the overlay 


segments. 


Creates new or 
replacement members for 
the user’s library. 


Writes a diagnostic 
listing of results to 
SYSPRINT. 
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Control Step: 


DOS Job Control 
program interven- 
tion: 


SYSIPT 


(Assembled object 
modules of FD 
macro instructions) 


@ Checks input data and 
creates Linkage Editor 
control statements. 


Writes output to SYSPCH. 


Writes a diagnostic 
listing of the Control 
step results to SYSLST' 


Reads the SYSIPT 


file into the 
SYSLNK file for 
input to the 
Linkage Editor. 


———> [Re] 


~——|> |] systst 


> [rene 


A Job Control 
statement is 
used to redefine 
the SYSPCH file 
as SYSIPT. 


Relocatable 
Library 


or 
re 


SYSLST 


SYSO00 
=I|JFDLIB 


User-defined 
FD program library 


Linkage Editor Step: 


e@ Creates the overlay 
program executed in the 
next step. 


Implementation: 
e User-written 
application 
program executed 


Storage Step: Core Image Library 


e@ Loads the overlay 


to transmit FD 
programs to the 
terminals. 


User-written 
application 
programs process 
the data that is 
gathered at the 
terminals. 


<ofee<|: 


SYSLST [<Q 


segments. 


Creates new or replacement 
members for the user’s 
library and writes them out 
to the library. 


Writes a diagnostic listing 
of the Storage step results 
out to SYSLST. 


<_ 


Overlay 
Program 


<a 
cae 


Resolves backward 
Origin instructions. 


Writes the overlay 
program out to a 
core image library. 


Writes a diagnostic 
listing of the Linkage 
Editor step results 
out to SYSLST. 


CARD 
TYPE COLUMNS CONTENTS 
ESD 1 12-2-9 punch 
2-4 Card type, which should be ESD 
5-10 Blank 
11-12 Variable field count. The number of 
bytes of information in the variable 

field (columns 17-64) 

13-14 Blank 

15-16 ESDID of the first CSECT definition 
in the variable field 

17-64 Variable field. From one to three 

ESD items, each in the following 

format: 

8 bytes - CSECT name, left justified 
and right padded with 
blanks, as needed 

1 byte - ESD type code, which 
should be a hexadecimal 
00 

3 bytes - CSECT address 

1 byte - Blank 

3 bytes - CSECT length 

65-72 Blank 
73-76 Deck 1D 
77-80 Card sequence number 
TXT 1 12-2-9 punch 
2-4 Card type, which should be TXT 
5 Blank 
6-8 Relative address of the first instruc- 
tion on the card 
9-10 Blank 
11-12 Byte count. The number of bytes in 
the information field (columns 17-72) 
13-14 Blank 
15-16 ESDID 
17-72 56-byte information field 
73-76 Deck ID 
77-80 Card sequence number 
END 1 12-2-9 punch 
2-4 Card type, which should be END 
5-39 Blank 
40-62 Version of the assembler 


and the date and time 
of the assembly 


optional 


63-72 Blank 
73-76 Deck ID 
77-80 Card sequence number 


Figure 3-3. Card Image Input Format Descriptions 


The contents of the four subfields are as follows: 


1. The name subfield contains the form name, left justified 
and padded to the right with blanks, as needed. This is 
the name by which the FD program will be known in the 
user’s FD program library. 

2. The count subfield commences with a binary zero and is 
incremented by one in each KUPB within a single FD 
program. However, if there was an error in the assembly 
of the program, the first subfield contains a binary -1. If 
the assembled program is incomplete, this subfield con- 
tains a binary -2. 


3-10 


3. The data subfield contains the actual instructions that are 
sent to the 3735 to control the terminal’s actions during 
forms creation and data capture. 

4. The data in the six-byte end-of-form subfield is also sent 
to the 3735. This subfield is set to all zeros in every 
KUPB except the last one in an FD program. In the last 
KUPB, it is set to all ones to indicate the end of the FD 
program. 


Figure 3-7 illustrates the format of a KUPB. Figure 3-8 
shows a complete FD program as it would appear in the 
input data set. 


Output Data 


The principal output data set of the FD utility is the user’s 
library of FD programs. This library is a partitioned data set 
(under OS) or an indexed sequential data set (under DOS) 
whose members are the individual FD programs. The mem- 
bers of this library may be stored under either of the follow- 
ing name types: 


@ The name used in the name field of the FDFORM macro, 
that is, the high-order eight bytes of the key field in all 
the KUPBs of a particular program. 


@ The temporary name assigned by the utility if FD pro- 
gram replacement is not specified in the user’s JCL or 
control cards. 


Temporary names are chosen from the lowest available 
name in the sequence IDFTEMPO through IDFTEMP9 
(under OS) or IJLFTMOO through IJLFTMO9 (under DOS). 
In any case, the FD program names are listed in the diagnos- 
tic listing produced in the Storage step. Any storage of a 
program under a temporary name is noted in this listing. 
Standard system facilities may be used later to rename or 
delete the programs stored under temporary names. 


Processing Data Description and Flow 


Data flow among the program units includes a variety of 
data types: 


@ The input object module data 


@ The object module IDFST (OS) or IJLFST, ISLFLOAD, 
and IJLFUPDT (DOS) 


@ The overlay segments of the Storage step 


The following paragraphs describe the changes these data 
types undergo during the execution of the FD utility. 


Input Object Module Data 


The input object module data undergoes changes during 
processing until its incorporation in the executable module 
of the Storage step. Initially, the data consists of 80-byte 
card images representing an object module deck. These 
card images are in the form of ESD, TXT, and END records. 
The Control step reads the individual card images into and 
out of main storage during validation, generates Linkage 


TXT CARDS 
T 


TX DECK SEQ. 
ID NO. 


ESD CARDS 


DECK SEQ. 
ID NO. 
73. 76/77 ~~ #80 


Figure 3-4. Input Module Physical Organization 


cera —inshensonine ao 486 BYTES ne et 


END-OF-ASSEMBLY 
INDICATOR 
— 4BYTES a 


NOTE: The last input CSECT may have six or less KUPBs and the 
four-byte end-of-assembly indicator is set to all ones. 


Figure 3-5. OS Input CSECT Example 
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i —§$— 486 BYTES — 


END-OF-ASSEMBLY 


INDICATOR 
a 6 BYTES | 
NOTE: The last input CSECT may have three or less KUPBs and the 


six-byte end-of-assembly indicator is set to all ones. 


Figure 3-6. DOS Input CSECT Example 


Bytes 


NAME Subfield 
(Same within each 
unpacked program) 


Key Field 


Figure 3-7. KUPB Format 


Editor control statements, and writes the card images and 
control statements to a utility file in auxiliary storage. The 
Linkage Editor, using the control statements generated in 
the Control step, transforms the card images into segments 
of an overlay program; each CSECT becomes one overlay 
segment. In the process, the card image input data becomes 
Linkage Editor output records. The ESD, deck identifica- 
tion, and sequence information that was validated in the 
Control step is removed during linkage editing. The TXT 
information, that is, the data in columns 17-72 of the TXT 
cards, remains unchanged, except that backward origins are 
resolved. The result of this processing is that the KUPBs 
retain the structure shown in Figure 3-7, but they become 
parts of overlay segments that may be loaded into main 
storage. Under OS, the overlay segments possess segment 
numbers 2,3,4...n;the root segment (IDFST) is num- 
bered 1. Under DOS, the segments’ phase names are the 
same as the input CSECTs’ names. Besides KUPBs, the 
only other data in each overlay segment is the four-byte 

or six-byte end-of-assembly indicator. 
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DATA 


me SLED TOR! 


End-of- 
Form 

Subfield 
(3H’‘0') 


SUBFIELD 


Form Description Unpacked 
Program Block 


Object Modules IDFST, (JLFST, IJLFLOAD, and 
IJLFUPDT 


IDFST: As previously stated, the object module IDFST, 
which is used in the OS version of the FD utility, is not 
executable until the Linkage Editor step has successfully 
finished executing. The Linkage Editor creates two tables 
for the module and resolves one V-type address constant 
contained in it. This V-type constant is a pointer to the 
load address of the first CSECT generated by the FD mac- 
f ros, that is, IDF1000. The two tables created are the seg- 
' ment table, SEGTAB, and the entry table, ENTAB. The 
Linkage Editor places the segment table at the start of 
IDFST and the entry table at its end, thus producing an 
executable load module. The load module IDFST and the 
linkage-edited CSECTs of the original input data, each 
of which is an individual segment of an overlay program, 
are written into a temporary load module library as a 
single overlay program. This program, which still bears 
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Figure 3-8. Typical Input FD Program 


the name IDFST, is executed in the Storage step as the 
GO module. 

For more detailed information about the resolution of 
the V-type address constant and the creation of the segment 
and entry tables, refer to the subsection of this section enti- 
tled “Linkage Editor Step Functions.” 


IJLFST, IFLFLOAD, and IJLFUPDT: As previously stated, 
the object modules IJLFST, IJLFLOAD, and IJLFUPDT, 
which are used in the DOS version of the FD utility, are not 
executable until the Linkage Editor step has successfully 
finished executing. The Linkage Editor creates the phases 
IJLFST, IJLFLOAD, and IJLFUPDT from the modules. 
The phases IJLFST, IILFLOAD and IJLFUPDT and the 
previously linkage edited CSECTs of the input data, each 
of which is an individual phase of an overlay program, are 
written into auxiliary storage as a single overlay program. 
This program is executed in the Storage step. 


Overlay Segments of the Storage Step 


Each overlay segment of the Storage step consists of KUPBs 
and the end-of-assembly indicator. The segments are called 
into main storage by the issuing of the SEGWT supervisor 


call (OS) or the LOAD macro (DOS). Each segment is 
brought into main storage when the processing of the pre- 
vious segment is complete, provided that the end-of- 
assembly indicator shows that another valid segment is 
available. The segment loading occurs during the larger pro- 
cess of writing the FD programs to the user’s library, but is 
independent from it. 

The KUPBs within each segment are examined serially. 
The data portions of the KUPBs, that is, bytes 10-485, are 
successively written to the user’s library until the end-of- 
form subfield indicates that the last KUPB in the program 
has been encountered. Under OS, the next Storage step 
function is to issue a STOW macro; under DOS, this action 
is not necessary. If the return from the STOW indicates 
that the FD program is the duplicate of an FD program that 
already exists in the user’s library, the utility may construct 
and consult a replacement table. (Under DOS, this replace- 
ment table is always constructed before the program 
attempts to process any KUPBs.) The purpose of this con- 
sultation is to determine whether the new FD program 
should replace the older program in the user’s library. If 
the program name is not found in the replacement table or 
if the user did not employ the replacement parameter, the 
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utility attempts to store the new FD program under a tem- 
porary name. The Storage step resumes processing with 
the next KUPB, if one is available. Otherwise, it examines 
the end-of-assembly indicator to determine whether there 
is another valid segment to be processed. 

The flow of data during the execution of the FD utility 
is shown in Figure 3-9 for OS and Figure 3-10 for DOS. 


FD UTILITY FUNCTIONS 


Control Step Functions 


The primary tasks of the Control step are (1) the validation 
of the input records produced by the FD macros and (2) 
the generation of Linkage Editor control statements and the 
concatenation of these statements with the input records. 
To accomplish these tasks, the Control step performs sev- 
eral interrelated functions during its execution. These 
functions are described in the following paragraphs. 

The first function of the Control step is the opening of 
the system input and output files and the utility file that 
receives the validated input records. Under OS, the program 
then determines whether these three files were opened suc- 
cessfully. If the file openings were successful, the program 
proceeds to the validation of the input records. Under DOS, 
this checking of the file openings is performed by the operat- 
ing system. 

There are three input record types: ESD, TXT, and 
END. Although the functions of these records are different, 
as are the fields within each one, two fields are common to 
all three types. These fields are (1) deck ID, columns 73-76, 
and (2) card sequence number, columns 77-80. The Control 
step validates these fields in all three record types; for TXT 
and END records, these are the only fields validated. In 
addition to validating these fields, the program also ensures 
that the record types are in the proper order. That is, an 
ESD record must be followed by another ESD record or 
TXT record; a TXT record must be followed by another 
TXT record or an END record; an END record must be fol- 
lowed by an ESD record (indicating that another FD pro- 
gram module follows) or an end-of-file indication. Other 
than the restrictions imposed by the system assembler, there 
are no limitations on the number of ESD and TXT records 
allowed in a single FD program module. However, only one 
END record per module is allowed. 

As previously stated only the deck ID and card sequence 
number fields of the TXT and END records are validated. 
On the other hand, the Control step validates the ESD 
records more rigorously. In any ESD record, there are from 
one to three ESD items specified in the ‘variable’ field, col- 
umns 17-64; only the last ESD record within a module may 
contain less than three ESD items. The fields that the Con- 
trol step validates in each ESD item are as follows: 


@ Name 
The eight-byte name of the external symbol, which is the 
name of a CSECT generated by the FD macros. For the 
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first ESD item of an input module, this field must con- 
tain IDF1000 (OS) or IJLF1000 (DOS). The value of 
each name field in succeeding ESD items must be one 
greater than the value of the name field in the immedi- 
ately preceding ESD item. If multiple input modules 
are present, the Control step renames the CSECTs of 
these modules so that the sequential progression is 
maintained in the output data set. 

e Type 
The one-byte ESD type code, which should be a hexadec- 
imal 00. 

e Address 
The three-byte address of the external symbol (CSECT) 
within the input module. For the first ESD item of 
an input module, this field must contain 0. The value 
of each address field in succeeding ESD items must be 
a progressive multiple of 2920 (OS) or 1464 (DOS). 

e Length 
The three-byte length field of the external symbol (CSECT). 
Under OS, this value should be 2920 in all ESD items 
except the last one in a module. The value of the length 
field in the last ESD item may be 490, 976, 1462, 1948, 
2434, or 2920. Under DOS, the value should be 1464 in all 
ESD items except the last one in a module. The value of the 
length field in the last ESD item may be 492, 978, or 


1464. 
The Control step validates these fields in each ESD item. 


After it validates an ESD item, it uses the ‘variable field 
count’ field to determine the presence or absence of addi- 
tional ESD items. If no more items are available, the pro- 


gram reads in the next record which may be either another 


ESD record or a TXT record. 
The OS and DOS versions of the FD utility operate dif- 
ferently to create the necessary Linkage Editor control 


statements. These different methods of operation are 


described in the following paragraphs. 


OS Method of Operation 
In validating the input, the OS Control step reads a single 


card image into main storage, validates that card image, then 


writes it out to the utility file. At no time during Control 
step processing are there two or more card images in main 
storage simultaneously. When all of the records in the 
entire input file have been validated and written out, the 
Control step creates and writes out Linkage Editor control 
statements. The purpose of these control statements is to 


provide the Linkage Editor, which is called into execution 


in the next job step, with the information necessary to pro- 
duce an overlay program. The control statements are writ- 


ten to the same utility file as the validated input records. 
The first control statement created and written out is an 
INCLUDE statement. Its purpose is to define the object 
module that will become the root segment of the overlay 
program. This module is IDFST. The Control step also 


SYSIN QS Card image object module data 
Control 
Step 
SYSUT1 — Validated ESD cards 
. Validated TXT cards 
ame Validated END card 
ay Linkage Editor control statements 
SYSDD 
ae Linkage ot oe 
Editor 
Step 
Overlay Program 
Root 
cs Segment 
SYSLMOD 60, 
1DF 1000 1DF1002 
St 
sa Overlay Segments 
USERLIB The key fields of the KUPBs have been 
Member B | removed and the FD programs are ready 
[ Member C to be sent to the terminals. 


Figure 3-9. OS FD Utility Data Flow 
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SYSIPT QS Card image object module data 
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Step 
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SYSIPT one Linkage Editor control statements 
eg Validated ESD cards 
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DOS 
Job 
Control 
SYSLNK 


Linkage Editor control statements 


Validated ESD cards 


Relocatable Library 
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Validated END card 


Linkage 


Editor 
SYS001 Step 
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Overlay Program 
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The key fields of the KUPBs have been used as the record keys 
and the FD programs are ready to be sent to the terminals. 
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Figure 3-10. DOS FD Utility Data Flow 


3-16 


IJLFnnnn 


creates and writes out one OVERLAY statement and one 
INSERT statement for each ESD item (input CSECT) that 
was validated. The purpose of these statements is to cause 
the Linkage Editor to transform each input CSECT into a 
segment of an overlay program. When all the necessary con- 
trol statements have been created and written out, the 
Control step writes a message to the system printer stating 
that the step has been completed successfully, then 
terminates. 

If a data error is encountered during the execution of the 
Control step, the step itself writes an error message out to 
the system printer, then continues processing with the next 
available module. Figure 3-11 represents the OS Control 
step’s method of operation. 


DOS Method of Operation 


In validating the input, the DOS Control step reads a single 
ESD card image into main storage and validates that card 
image, but it does not write out the card image. Instead, it 
continues to read and validate the ESD records until the 
first TXT card is encountered. At that point, the program 
creates and writes out the necessary Linkage Editor control 
statements. Next, it recreates and writes out the ESD rec- 
ords, then reads in and writes out the remaining TXT and 
END records of the input module. If multiple input mod- 
ules are present, the entire process is repeated for each 
module. 

The purpose of the control statements is to provide the 
Linkage Editor, which is called into execution in the next 
job step, with the information necessary to produce an over- 
lay program. The control statements are written to the 
same file as the validated input records. The first control 
statements created and written out are PHASE and 
INCLUDE statements for the modules IJLFST, IJLFLOAD, 
and IJLFUPDT, which are the processing phases of the 
overlay program executed in the Storage step. Next, the 
program writes out a PHASE and an INCLUDE statement 
for each input CSECT. The purpose of these statements is 
to cause the Linkage Editor to transform each input CSECT 
into an overlay phase. If multiple input modules are pres- 
ent, the phase names inserted in the PHASE statements for 
the CSECTs of these modules are changed to maintain a 
sequential progression in the output file. 

When all the necessary control statements have been cre- 
ated and written out, the Control step writes a message to 
the system printer stating that the step has been completed 
successfully, then terminates. If an error is encountered in 
the input to the Control step, the step itself writes an error 
message out to the system printer, then terminates. Figure 
3-12 represents the DOS Control step’s method of opera- 
tion. 


Linkage Editor Step Functions 


The primary task of the Linkage Editor step is the creation 
of an executable overlay program from the object module 


IDFST (OS) or IJLFST (DOS) and the validated input data. 
While the methods of operation used to accomplish this task 
are similar in the OS and DOS versions of the Linkage 
Editor, enough differences exist to merit a separate discus- 
sion of each method. These methods are described in the 
following paragraphs. 


OS Method of Operation 


The first function of the Linkage Editor step is to read the 
input records from SYSLIN (formerly SYSUT1) and place 
them in a work file. When all of the object module records 
have been read, the Linkage Editor encounters the first of 
the control statements that were generated by the Control 
step. The first statement, the INCLUDE statement, causes 
the Linkage Editor to fetch the object module IDFST from 
either SYS1.LINKLIB or a user’s module library and place 
it in the work file. 

The next set of control statements read in, the OVER- 
LAY and INSERT statements, causes the Linkage Editor 
to perform the following functions: 


e@ Transform the CSECTs, one by one, into segments of an 
overlay program and assign segment numbers 


@ Resolve backward origins within the CSECTs 


@ Construct a segment table at the front and an entry table 
at the rear of IDFST to produce the root segment of the 
overlay program executed in the Storage step 


The segment table, SEGTAB, consists of a 28-byte head- 
ing plus n four-byte entries, where n is the number of 
overlay segments that were created from an equal number 
of input CSECTs. The purpose of the segment table is to 
contain information about the relationship of the segments 
in the overlay program. Also, during the execution of the 
overlay program, this table indicates which segment are 
either in main storage or waiting to be loaded. Figure 3-13 
illustrates the contents of the segment table. 

The entry table, ENTAB, consists of two 12-byte entries. 
The first entry is created in response to a four-byte V-type 
address constant that is contained within IDFST. The 
second entry is the standard last ENTAB entry, which is 
used for linkage to the Overlay Supervisor. Figure 3-14 
illustrates the contents of the entry table. For more infor- 
mation about the generation and composition of the seg- 
ment and entry tables, refer to the JBM System/360 Opera- 
ting System Linkage Editor Program Logic Manual, order 
number GY28-6610. 

The four-byte V-type address constant mentioned in the 
preceeding paragraph is a pointer to the load address of the 
first CSECT generated by the FD macros, that is, of 
IDF1000. It is resolved by setting its low-order three bytes 
to the address of the entry table. The high-order byte is set 
to a hexadecimal 02, which is the segment number of the 
segment containing the single CSECT IDF1000. 

When the Linkage Editor has finished transforming all of 
the input CSECTs into overlay segments, it writes out the 
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INPUT PROCESS OUTPUT 


1 Open files and check opening. 


SYSPRINT 


error msg 


ESD CARD PROCESSING 


Read in ESD card from SYSIN.* 


Validate ESD card.* ysis 


Put out ESD card to SYSUT1.* 


(Repeat steps 2 through 4 until all 
ESD cards are validated.) 


TXT Card 


——a TXT CARD PROCESSING maar 


Read in TXT card from SYSIN.* 


Put out TXT card to SYSUT1.* 


(Repeat steps 5 and 6 until all TXT 
cards are processed.) 


5 
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C | C 


END CARD PROCESSING 


TXT 
Card 
Images 


END Card 
image 


Linkage Editor 
Control 
Statements 


Read in END card from SYSIN.* 


Put out END card to SYSUT1.* 


Read in next record.* 


Is it an end-of-file indicator? 


YES NO—Return to step 3. 


CONTROL CARD CREATION 


Create Linkage Editor Control 
Statement. 


11 


12 Write the Linkage Editor control 
statement out to SYSUT1.* 


(Repeat steps 11 and 12 until all of 
the necessary control statements are 
created and written out.) 


13 Write out completion message to 
SYSPRINT.* — SYSPRINT 


14 Exit to the operating system. 


*If an error is encountered in an input card field, the program writes an 
error message out to SYSPRINT. If an unrecoverable I/O error is encoun- 
tered, the program writes an error message out to SYSPRINT, if that file 
is available, or to the operator console, then terminates. 


Description Routine Chart 


Opens and checks the opening of the SYSIN, SYSPRINT, CNTLINIT 
and SYSUT1 files. 


Reads the ESD card into the input area, OBJCARD, and GETCHECK 
validates the deck ID, card sequence number, and 
card type fields. 


Validates the name, type, address, and length fields ESDPROC 
of every ESD item on the card. 


Puts out the card to the sequential file SYSUT1. PUTCARD 


Reads the TXT card into the input area, OBJCARD, and GETCHECK 
validates the deck ID, card sequence number, and card 
type fields. 


Puts out the card to the sequential file SYSUT1. PUTCARD 


Reads the END card into the input area, OBJCARD, and GETCHECK 
validates the deck ID, card sequence number, and 
card type fields. 


Puts out the card to the sequential file SYSUT1. PUTCARD 


Reads in the next record, which should be an GETCHECK 
end-of-file indicator or the first ESD card of the 
next input module. 


e YES - Transfers control to step 11. TXTPROC 
e NO - Returns control to ESDPROC for the GETCHECK 
processing of the new object module. 


Creates the necessary INCLUDE control statement for CNTLSTMT 
IDFST and the OVERLAY and INSERT statements for the 

input CSECTs. 

Puts out the statement to the sequential file SYSUT1. PUTCARD 
Informs the user of the successful completion of the MGSFAN/ 
Control step. DIAGWTR 


Closes the SYSIN, SYSPRINT, and SYSUT1 files and CNTLEND 
returns control to the operating system. 


Figure 3-11. OS Control Step Method of Operation (Part 3 of 3) 


entire overlay program (GO module) to the output module the current Linkage Editor practices. If the format of 
library SYSLMOD or to a user-defined output module either of these tables is altered by a subsequent release of 
library. Next, it writes a message to SYSPRINT stating that the Operating System, code changes in the module 
the step has been completed sucessfully, then terminates. IDFST may be necessary. If the table formats are altered 
Note: The proper functioning of the GO module and the code changes are made, the new version of the 
executed in the Storage step depends upon the construc- FD utility will not execute properly under an older 
tion of the segment and entry tables in accordance with release of the Operating System. 
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DOS Method of Operation 


The first function of the DOS Linkage Editor is to read the 
control statements and validated object module records in 
from SYSLNK and place them in the SYSO01 work file. 
The Linkage Editor begins processing the control statements 
as encountered. The first six control statements are the 
PHASE and INCLUDE statements for the object modules 
IJLFST, IJLFLOAD, and IJILFUPDT. These statements 
cause the Linkage Editor to fetch the object modules from a 
relocatable library and place them in the work file. The 
next control statements are the PHASE and INCLUDE 
statements for the following input CSECTs. These state- 
ments cause the Linkage Editor to transform the CSECTs, 
one by one, into overlay phases and to resolve backward 
origins within the CSECTs. When the Linkage Editor has 
finished processing the control statements, it writes out the 
entrie overlay program to the core image library. Finally, 

it writes out a storage map to SYSLST, stating that the step 
has been completed successfully, then terminates. 


Storage Step Functions 


The primary tasks of the Storage step are to arrange the FD 
programs into a usable format and to place them in a user- 
defined FD program library. Although the purposes of the 
Storage step are similar in the OS and DOS versions of the 
utility, the methods used to achieve the purposes differ 
widely. These different methods of operation are described 
in the following paragraphs. 


OS Method of Operation 


The first function of the OS Storage step is the opening of 
the system output file and the user’s FD program library 
file. The program then determines whether these two files 
were opened successfully. If the file openings were success- 
ful, the program proceeds to the validation of the param- 
eters passed from the user’s JCL. If the parameters are 
valid, the program will construct a replacement table when 
it encounters a duplicate FD program. The purpose of the 
table is to specify the action the Storage step should take if 
a new FD program bears the same name as an FD program 
already present in the user’s library. Two alternatives exist: 
(1) the program may replace the old program in the user’s 
library or (2) the new program may be stored under a tem- 
porary name. 

The user specifies the replacement of old FD programs 
through the JCL PARM feature. If the user wishes to 
replace all old duplicate programs with the new programs, 
he should code PARM=“REPLACE’ on the EXEC card that 
calls for IDFST. In some cases, the user may wish to 
replace only some particular old programs. To accomplish 
this, he must name those programs specifically by coding 
PARM=‘REPLACE=(namel,name2,...,namen)’. The 
names entered must be the same as the names entered in the 


name field of the FDFORM macros and a maximum of 
twenty names may be specified. If the user does not name 
the programs to be replaced or does not employ the PARM 
feature, the duplicate programs are stored as new members 
under temporary names. Temporary names are chosen from 
the lowest available name in the sequence IDFTEMPO 
through IDFTEMP9. If these temporary names have been 
exhausted, the program is not stored. In any case, the FD 
program names and the actions taken by the Storage step 
are listed in the diagnostic listing produced by the Storage 
step. 

The next function of the Storage step is to load and pro- 
cess the overlay segments, one segment at a time. The 
program serially examines the KUPBs within each segment. 
It checks the name and count subfields of each KUPB, then 
writes out the 476-byte unpacked program block field to 
the user’s library. By writing out only the unpacked pro- 
gram block field, the Storage step effectively deletes the 10- 
byte key field, thereby arranging the FD programs into a 
usable format. The process of reading in and writing out 
the overlay segments continues until the end-of-form 
indication is detected. The appropriate form of the STOW 
macro is then issued. If the return from the STOW indicates 
that the FD program is the duplicate of an FD program that 
already exists in the user’s library, the utility will construct 


and consult the replacement table. The purpose of this 
consultation is to determine whether the new FD program 


should replace the older program in the user’s library. If 
the program name is not found in the replacement table or 
if the user did not employ the replacement parameter, the 
utility attempts to store the new FD program under a tempo- 
rary name. The reading and writing of the FD programs 
continues until the end-of-assembly indication is encoun- 
tered. Asa part of the FD program processing, the Storage 
step composes and writes out a diagnostic listing to the 
system printer. This listing states the names of all FD pro- 
grams encountered and the actions taken by the program in 
each case (that is, stored under its proper name, stored 
under a temporary name, or not stored at all). The pro- 
gram then terminates. 

If an error condition is encountered at any time during 
the execution of the Storage step, the step itself writes an 
error message out to the system printer, if available, or to 
the operator console. It ceases processing at the point of 
the error and terminates. Figure 3-15 represents the OS 
Storage step’s method of operation. 


DOS Method of Operation 


The first function of the DOS Storage step is the opening of 
the SYSIPT and SYSLST files. The next function is the 
validation and processing of the user-coded FD utility con- 
trol statements in the SYSIPT file. There are three types of 
control statements that the user may code: (1) DEVICE, 
(2) OPTION, and (3) RPLACE. 
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INPUT PROCESS OUTPUT 


SYSIPT 
1 Open all I/O files. 


—7 ESD CARD PROCESSING 


Cards Read in an ESD card from SYSIPT.* 


Validate the ESD card.* 


(Repeat steps 2 and 3 until all of 
the ESD cards are validated.) 


CONTROL CARD CREATION 


Create a Linkage Editor control 
statement. SYSPCH 


Linkage Editor 
Control 
Statements 


Write the Linkage Editor control 
statement out to SYSPCH. 


(Repeat steps 4 and 5 until all of 
the necessary control statements 
are created and written out.) 


ESD Card 
Images 


TXT Card 
ESD CARD RECREATION anes 


Recreate an ESD card. 


Write the ESD card out to SYSPCH. 


(Repeat steps 6 and 7 until all of 
the ESD cards are recreated and 
written out.) 
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C C 


TXT CARD PROCESSING 


( |H= Read in a TXT card from SYSIPT.* 


Write out the TXT card to SYSPCH.* TXT Card 


Images 


(Repeat steps 8 and 9 until all of 
the TXT cards are processed.) 


END CARD PROCESSING 


Read in the END card from SYSIPT.* 
Write out the END card to SYSPCH. 


Read in the next record.* 


Is it an end-of-file indicator? 


YES NO—Return to step 3. 


14 Write out the completion message to —— SYSLST 
SYSLST. 


15 Exit to the operating system. 


*If an error is encountered in an input card field, the program writes an 
error message out to SYSLST, then terminates. If an unrecoverable I/O 
error is encountered, the DOS Supervisor terminates the Control step and 
returns control to the DOS Job Control program. 


Figure 3-12. 


Description 


Opens the SYSIPT, SYSPCH, and SYSLST files. 


Reads the ESD card into an I/O buffer and validates 
the deck ID, card sequence number, and card type 
fields. 


Validates the name, type, address, and length fields 
of every ESD item on the card. 


Creates the necessary PHASE and INCLUDE control 
statements for the object module IJLFST and for 
the input CSECTs. 


Writes out the Linkage Editor control statement to 
the sequential file SYSPCH. 


Recreates an ESD card in an I/O buffer, using 
predictable values and decrementing the count of 
ESD cards to be created. 


Writes out the newly recreated ESD card to the 
sequential file SYSPCH. 


Reads the TXT card into an I/O buffer and validates 
the deck ID, card sequence number, and card type 
fields. 


Writes out the TXT card to the sequential file 
SYSPCH. 


Reads the END card into an I/O buffer and validates 
the deck ID, card sequence number, and card type 
fields. 


Writes out the END card to the sequential file 
SYSPCH. 


Reads in the next record, which should be an 
end-of-file indicator or the first ESD card of the 
next input module. 


e YES - Transfers control to step 14. 
e NO - Returns control to ESDPROC for the 
processing of the new object module. 


Informs the user of the successful completion of 
the Control step. 


Closes the SYSIPT, SYSPCH, and SYSLST files and 
returns control to the operating system. 


DOS Control Step Method of Operation (Part 3 of 3) 


Routine 


CNTLINIT 


GETCHECK 


ESDP ROC 


CNTLSTMT 


PUTCARD 


CNTLSTMT 


PUTCARD 


GETCHECK 


PUTCARD 


GETCHECK 


PUTCARD 


GETCHECK 


TXTPROC 
GETCHECK 


MSGFAN/ 
DIAGWTR/ 
PUTCARD 


Chart 


Lae as Address of Data Control Block (DCB) used to load module i. 
Last segment Highest segment no. Last segment Highest segment no. 
number of region 1 in storage-region 1 number of region 2 in storage-region 2 
Last segment Highest segment no. Last segment Highest segment no. 
number of region 3 in storage-region 3 number of region 4 in storage-region 4 


(Not used in the Fixed-Task Supervisor) ™ 


(Not used in the Fixed-Task Supervisor) 


Previous segment * 
number for segment 1 


Previous segment Address of entry table entry (when caller 


zero 


number for segment 2 chain exists) - Indicator 


Previous segment Address of entry table entry (when caller Status 
number for segment N chain exists) * Indicator 
eerie eee end bytes Serr earn — 


TEST indicator — specifies that this module is ‘‘under test’’ using 
TESTRAN. (Bit 1) Initialized by program fetch. 
Highest segment no. in storage — is initially set to 00 except for 
region 1 which is initially set to 01 by linkage editor. 


Status indicator — indicates the status of this segment with the 
two last bits of the entry table address field as follows: 


00 — segment is in main storage as a result of a branch to the segment. 
10 — segment is in main storage, no caller chain exists. 

01 — segment is not in main storage, but is scheduled to be loaded. 

11 — segment is not in main storage. 


The status indicator for segment 1 is initially 
set to 10, all the rest are initially set to 11. 


* set to zero by linkage editor 


Figure 3-13. SEGTAB Contents 


Unconditional branch to last Address of referred “to” seg Previous Caller 
entry-BC 15, DISP (15,0) to symbol number (zero initially) 
L 15,4(0,15) Loads GR15 with "from" Address of segment 
— 2 bytes rt — 2 bytes > 2 bytes ++ 2 bytes + 1 byte +— 3 bytes ——+ 


DISP — is the displacement, in bytes, of this entry from the last entry. 
‘to’ segment number — is the number of the segment containing the symbol being referred to. 
“from” segment number — is the number of the segment that contains this entry table. 


Figure 3-14. ENTAB Contents 


Logic Of The Form Description Utility 3-25 


9T-E 


(€ JO [ }1eg) UOT}VIOdGO Jo poyop do7§ aseI0I§ SO “ST-¢ oINIIy 


INPUT PROCESS 


SYSLMOD 1 Open files and check opening.* 


IDFST 


(DF 1000 
IDF 1001 
IDF 1002 


2 Validate the passed parameters and 
create the replacement table. 


SEGMENT PROCESSING 


3 Load an overlay segment from 
SYSLMOD.* 


4 Determine the replacement status of 
the new FD program. 


5 Write out the unpacked program block 
field of a KUPB to the SYSLIB file.* 


(Repeat step 5 until all of the KUPBs 
within the segment have been processed 
or until the end-of-form indication is 
encountered. Repeat steps 3 and 5 

until all of the KUPBs within a single 
FD program have been processed.) 


OUTPUT 


SYSLIB 


MEMBER A 
MEMBER B 


MEMBER C 


+ 
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6 Issue the appropriate STOW macro.* 


7 Are there any more KUPBs to be 
processed in this segment? 


NO YES—Return to step 4. 


g Are there any more segments to be 
processed? 


NO YES—Return to step 3. 


Q Compose the completion message. 


10 Write the message out to SYSPRINT.* 


11° Exit to the operating system. 


*If an unrecoverable I/O error is encountered, the program writes an error 
message out to SYSPRINT, if that file is available, or to the operator 
console. It then terminates. 


SYSPRINT 


Description 


Opens and checks the opening of the SYSLIB (user’s 
library) and SYSPRINT files. 


Ensures that the passed parameters are in the 
proper format, then builds the replacement table, 
REPLTAB. 


Issues a SEGWT supervisor call to bring the 
overlay segment into main storage. 


Consults REPLTAB to determine the replacement 
status of the FD program. 


Examines the count subfield of the KUPB to ensure 
that it is in the proper sequence, then writes out 
the 476-byte unpacked program block field to the 
user’s FD program library. 


Uses the previously determined replacement status 
to determine the form of the STOW macro to be used, 
then issues the STOW command. 


Resumes processing with the next KUPB, if one is 
available in the current segment. 


Resumes processing with the next segment, if one is 
available. 


Composes the completion message, which contains the 


names of all FD programs processed, their lengths 
(number of KUPBs), and the action taken by the 
Storage step. 


Informs the user of the successful completion of the 
Storage step. 


Closes the SYSLIB and SYSPRINT files and returns 
control to the operating system. 


Routine Chart 


STGINIT 


PARMPROC 


SEGPROC 


NEWMEM 


NEWMEM 


NEWMEM 


NEWMEM 


MSGFAN/ 
DIAGWTR 


DIAGWTR 


STGEND 


Figure 3-15. OS Storage Step Method of Operation (Part 3 of 3) 


e@ The DEVICE control statement is used to specify the 
type of DASD on which the user’s FD program library 
resides. It must be coded in the following format: 

// DEVICE=2311 
or // DEVICE=2314 


@ The OPTION control statement is used to specify the 


type of operation to be performed by the Storage step. 


It must be coded in the following format: 


// OPTION=LOAD 
or // OPTION=LOADFST 
or // OPTION=UPDATE 
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@ The RPLACE control statement is used to specify which 
old FD programs are to be replaced by new (duplicate) 
FD programs during an update operation. It must be 
coded in the following format: 


// RPLACE 
or // RPLACE=name 
where “‘name”’ is the same as the name of an FD program 
specified in the name field of that program’s FDFORM 
macro. 


The user specifies the LOAD option as the first step of a 
two-step operation when he is creating a new FD program 


library. The selection of this option during the execution 
of the phase IJLFST causes IJLFST to fetch and execute 
the overlay phase IILFLOAD. This phase initializes the 
new library by loading the first FD program from the core 
image library and writing it out to IJFDLIB (the user’s 
ISAM FD program library). The second step is accom- 
plished when the user specifies the LOADFST (“‘load first’’) 
option during a second execution of IJLFST. The selection 
of this option causes IJLFST to fetch and execute the over- 
lay phase IILFUPDT. This phase, when executing under the 
LOADFST option, loads and writes out the remaining FD 
programs, thus completing the creation of the new FD pro- 
gram library. When the user wishes to update an existing 
FD program library, that is, to add new FD programs or 
replace old ones, he specifies the UPDATE option. The 
selection of this option causes IJLFST to load and execute 
the overlay phase IJLFUPDT. IJLFUPDT, when executing 
under the UPDATE option, performs the necessary addi- 
tions and/or replacements and revises the library’s index to 
reflect these changes. Replacements are performed in accor- 
dance with the operand (s) specified in the RPLACE control 
statement (s). 

As previously stated, the user uses the RPLACE control 
statements during an update operation to control the 
replacement of old FD programs by new duplicates. The 
use of these control statements in the input stream causes 
IJLFST to construct a replacement table, which is passed to 
IJLFUPDT when that phase is loaded. If the user wishes 
to replace all old duplicate FD programs with the new pro- 
grams, he should code “‘// RPLACE”’. In some cases, 
however, the user may wish to replace only some particular 
old programs. To accomplish this, he must name those 
programs specifically by ‘‘// RPLACE=name’”’, as described 
previously. In this format, only one FD program name may 
be specified on a control statement, and a maximum of 
twenty FD programs may be so specified. If the user does 
not name the programs to be replaced or does not employ 
the RPLACE control statement at all, the duplicate pro- 
grams are stored as new members under temporary names. 
Temporary names are chosen from the lowest available 
name in the sequence IJLFTMOO through IJLFTMO9. If 
these temporary names have been exhausted, the program 
is not stored. In any case, the FD program names and the 
actions taken by the Storage step are listed in the diagnos- 
tic listing produced by the Storage step. 

The processing of the FD programs in the Storage step is 
basically the same in each type of operation (LOAD, 


LOADFST, or UPDATE). The overlay phases created in the 
Linkage Editor step are loaded and processed one by one. 
The program processes the KUPBs within each phase 
serially. It checks the name and count subfields of a KUPB, 
then writes out the 476-byte unpacked program block field 
to IJFDLIB with a 10-byte key field, thereby arranging 

the FD programs into a usable format. If IJLFLOAD 
encounters any type of error during this processing, it issues 
a descriptive error message and terminates immediately. 
IJLFUPDT, on the other hand, responds to an error within 
an FD program by flushing that program, issuing an error 
message, and continuing processing with the next available 
FD program. However, environmental errors, such as a data 
area overflow, cause IJLFUPDT to issue a descriptive error 
message and terminate. 

The response of the Storage step to the detection of a 
duplicate FD program depends upon the type of operation 
being performed. If the duplicate is detected during a 
LOAD operation, the program issues an error message and 
terminates. If a LOADFST operation is in progress, the 
program automatically replaces the old FD program with 
the new one. If the UPDATE operation is being performed 
when the duplicate FD program is encountered, the program 
consults the previously constructed replacement table. The 
purpose of this consultation is to determine whether the 
new FD program should replace the older program in the 
user’s library. If the user has specified // RPLACE, the 
older program is replaced automatically. However, if 
// RPLACE was not specified, then the program must search 
the replacement table for the name of the duplicate FD pro- 
gram. If the program finds the FD program’s name in the 
replacement table, it replaces the older FD program with 
the new one. If the FD program’s name is not found or if 
the user did not employ any // RPLACE control statements, 
the program attempts to store the FD program under a 
temporary name, as described previously. 

The loading and writing of the FD programs continues 
until all of the overlay phases have been processed. Asa 
part of this processing, the Storage step composes and 
writes out a diagnostic listing to the system printer. This 
listing states the names of all FD programs encountered and 
the action taken by the Storage step in each case (that is, 
stored under its proper name, stored under a temporary 
name, Or not stored at all). When all processing has been 
completed, the program writes out a message stating the 
fact, then terminates. Figure 3-16 represents the DOS Stor- 
age step’s method of operation. 
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INPUT PROCESS OUTPUT 
1 Open SYSLST and SYSIPT 


/] OPTION=LOAD | 
—— 2 Read and validate the 
control cards 


SYSIPT 

3 Close SYSLST and SYSIPT 

4 Was an UPDATE operation 

specified? 
\ 
-_ NO YES Ww 

5 Wasa LOAD operation specified? 

SYSLOG 


\o” 


<—e- i = 
ap 6 FETCH and pass control to 

: | JLFLOAD  =—_ 
7 WLFLOAD | 


a —— hh 7 FETCH and pass control to | 


_-TaeFurot IJLEUPDT 


data flow 


—) control flow 
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INPUT 


A 
| 


SYSLNK 


C 


PROCESS 


> = 


Open IJFDLIB and SYSLST 


Load an overlay phase into main 
storage from SYSLNK 


Validate the name and count subfields 
of a KUPB within the phase 


Write the validated KUPB out to IJFDLIB 


(Repeat steps 3 and 4 until all of the 
KUPBs within the phase have been 
validated and written out. Repeat steps 
2 through 4 until all of the phases on 
SYSLNK have been processed.) 


Write a message out to SYSLST 
indicating successful completion 


Write an EOF indication out to 
IJFDLIB 


Close IJFDLIB and SYSLST 


Exit to the operating system 


OUTPUT 


IJFDLIB 


SYSLST 


>o000 
9o0 60 


Description Routine 


Each overlay phase is loaded into a 1464-byte area within LOADRTN 
IJLFLOAD named LOADAREA. The LOAD macro is 
used to accomplish this task. 


If either of the fields is invalid, control is passed to the RCDCHK 
message Fan-in routine, MSGFAN, for the printing of an 

explanatory error message, and then to the End-of-Job 

routine, EOJRTN. 


The program first issues a SETFL macro to initialize the ISMPUT 
output data area, then writes the KUPB out. If the 

record is not written out properly, the program analyzes 

the error, then passes control to MSGFAN and 

EOJRTN. 


Figure 3-16. DOS Storage Step Method of Operation (Part 3 of 5) 


Chart 
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SYSLNK 


PROCESS 


C 


1 Open IJFDLIB and SYSLST 


2 Load an overlay phase into main 
storage from SYSLNK 


3 Validate the name and count subfields 
of a KUPB within the phase 


4 Were the fields valid? 


YES m_ * 


1°) 


\ 


5s Write the validated KUPB out to IJFDLIB 


(Repeat steps 3 through 5 until all of the 


Print out a message defining the 
error, flush the erroneous FD 

program, and resume processing 
with the next FD program at 
step 2. 


KUPBs within the phase have been 
validated and written out. Repeat steps 
2 through 5 until all of the phases on 
SYSLNK have been processed.) 


6 Write a message out to SYSLST 
indicating successful completion 


7 Write an EOF indication out to 


IJFDLIB 


8 Close IJFDLIB and SYSLST 


9 __—sExit to the operating system 


OUTPUT 


IJFDLIB 


— 


SYSLST 


Description Routine 


Each overlay phase is loaded into a 1464-byte area within LOADRTN 
IJLFUPDT named LOADAREA. The LOAD macro is 
used to accomplish this task. 


The program first determines whether or not the KUPB is ISMPUT 
a duplicate. If it is, and it is supposed to be replaced, the 
program replaces it in IJFDLIB. If it is a duplicate, but is 
not supposed to be replaced, the program stores it under 


a temporary name. If the KUPB is not a duplicate, the 
program checks for the following I/O errors: (1) DASD 
error, (2) wrong length record, (3) EOF written out, 

(4) no output record found, and (5) overflow area full. 

If any of these errors is found and cannot be corrected, the 
program prints out an error message and terminates. 


Figure 3-16. DOS Storage Step Method of Operation (Part 5 of 5) 


Chart 


FD UTILITY ORGANIZATION 


The aims of the FD utility, which were stated in the 
previous section, are accomplished through the logical 
organization of the program in three sequential job steps: 
Control step, Linkage Editor step, and Storage step. The 
Control step verifies the correctness of the object module 
input (except that data generated in columns 17-72 of the 
TXT card images) and generates the necessary Linkage 
Editor control statements for the next step. The Linkage 
Editor step performs the linkage editing of the input object 
modules, under control of the control statements generated 
in the first step. The Linkage Editor step also includes the 
object module IDFST (under OS) or IJLFST, IJLFLOAD, 
and IJLFUPDT (under DOS) in the input. The third and 
last step, the Storage step, is the execution of the linkage- 
edited overlay program. The data originally generated by 
the FD macro assembly is brought into main storage as 
overlay segments and put out to the user’s private data set 
in 476-byte blocks. Additionally, an optional JCL param- 
eter (OS) or control statement (DOS) may be used to allow 
the storage of FD programs whose names are the same as 
existing members of the user’s data set. 

Under OS, the program is comprised of three modules: 


IDFCT The Control step load module; 

IDFMO1 The message module that contains the messages 
put out to SYSPRINT or the operator console; 

IDFST The object module that becomes the root seg- 
ment of the overlay program executed in the 
Storage step. 


Under DOS, the program is comprised of five modules: 


IJLFCT The Control step phase; 

IJLFMO1 The message module that contains the messages 
put out to SYSLST; 

IJLFST The object module that becomes the root phase 
of the overlay program executed in the Storage 
step; 

IJLFLOAD The object modules that become Storage step 


overlay IJLFUPDT phases for the processing of 
the FD programs. 
Figures 3-17 and 3-18 illustrate the residency of these mod- 
ules in auxiliary storage for OS and DOS, respectively. 


Control Step Organization 


Although the organization of the modules IDFCT and 
IJLFCT is similar, enough differences exist to merit a 
separate discussion of each. These modules are described 
in the following paragraphs. 


Section 3: Program Organization 


IDFCT Organization 


The load module IDFCT is logically organized in 10 rou- 
tines, an 80-byte card storage area, and three data control 
blocks (DCBs). Figure 3-19 represents the physical organi- 
zation of IDFCT. The logical flow of the 10 routines is 
graphically represented in Charts OA1 through OAS at the 
rear of this section. Figure 3-20 illustrates the hierarchy of 
the routines within IDFCT. 


CNTLINIT - Control Initial: The control initial routine 
opens and tests the opening of the SYSIN, SYSUT1, and 
SYSPRINT files. Control passes automatically to the ESD 
processor routine unless one of the files fails to open prop- 
erly. If the opening of either SYSIN or SYSUT1 fails, 
CNTLINIT gives control to the message fan-in routine so 
that a message may be written to the system printer. If the 
opening of SYSPRINT fails, CNTLINIT writes a message 
out to the operator console, then terminates. 

ESDPROC - ESD Processor: The ESD processor routine 
receives control from CNTLINIT at the start of processing. 
It may also receive control from the TXT processor routine 
(TXTPROC) if multiple input modules are present. 
ESDPROC first invokes the get and check an input record 
routine (GETCHECK) to read in a card from SYSIN. If the 
card that is read in is a TXT card, the ESD processor trans- 
fers control to TXTPROC. Otherwise, it validates the name 
field, type code, address field, and length field of each ESD 
item on the card. Next, the routine invokes the put out a 
card routine (PUTCARD) to put the validated card out to 
SYSUT1, then again invokes GETCHECK to read in another 
card. Finally, when all of the ESD cards have been vali- 
dated and the first TXT card has been read in, it gives 
control to TXTPROC. If ESDPROC encounters an error 
during processing, it ceases processing immediately and gives 
control to the appropriate point in the message fan-in 
routine so that a descriptive error message may be written 
out to the SYSPRINT file. 


TXTPROC - TXT Processor: The TXT processor routine 
receives control from the ESD processor routine after the 
first TXT card has been read into main storage. It invokes 
PUTCARD to put out that first TXT card, then alternately 
invokes GETCHECK and PUTCARD to read in and put 
out the remaining TXT cards. TXTPROC performs this 
reading and writing function until it encounters an END 
card. At that point, it puts out the END card and reads 
the next record. If the next record read is the end-of-file 
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Figure 3-17. OS FD Utility Auxiliary Storage Residency 


System Private 
Residence Library 
Volume Volume * 


Step 2 
Output 


Core Image Library 


eee 


* 
* 
* 


* If the Private Library Volume is not used, all of the modules are 
written on the System Residence Volume. 


** These modules are linkage edited during system generation. IJLFST 


may reside on either volume. 
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Figure 3-18. DOS FD Utility Auxiliary Storage Residency 


indication, the routine passes control to the create control 
statements routine (CNTLSTMT). However, if the next 
record is an ESD card, then multiple input object decks are 
present and the routine sets the multiple object deck indi- 
cator (NEWJOB) to one and the address counter 
(ADDRCTR) to zero, then returns control to ESDPROC. 
On the other hand, if the next record fead is neither an end- 
of-file indication nor an ESD card, then an error condition 
exists. This error is detectable by GETCHECK. If it occurs, 
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Core Image Library 


Relocatable Library 


TXTPROC does not regain control from GETCHECK. 
Rather, GETCHECK passes control to the appropriate point 
in the message fan-in routine so that a descriptive error mes- 
sage may be written out to SYSPRINT. 


CNTLSTMT - Create Control Statements: The create con- 
trol statements routine receives control from the end-of- 
file subroutine that is contained within TXTPROC. By 

the time it gains control, all ESD, TXT, and END cards have 


ESD Processor 


Write Operator 


Figure 3-19. Module IDFCT Physical Organization 


been written out to SYSUT1. The purpose of CNTLSTMT 
is to create and write out the Linkage Editor control state- 
ments necessary to produce the overlay program (GO mod- 
ule) that is executed in the Storage step. As soon as 
CNTLSTMT creates a new control statement, it invokes 
PUTCARD to write it out to the SYSUT1 file. The first 
statement created is the INCLUDE control statement, 
which requests the Linkage Editor to use an additional data 
set as input. The INCLUDE statement specifies the ddname 
of the DD statement that describes the object module 
IDFST. The format of this statement is as follows: 


pINCLUDE SYSDD(IDFST) 


When this statement has been created and written out, 
CNTLSTMT creates and writes out a series of OVERLAY 


Control Initial (CNTLINIT) 


(ESDPROC) 


(WTORTN) 


and INSERT statements. The format of these statements 
is as follows: 


POVERLAY A 

bINSERT [DFnnnn 

where [DFnnnn is the name of an input CSECT that will 
become an overlay segment. 


CNTLSTMT creates only one INCLUDE statement, but it 
creates one OVERLAY statement and one INSERT state- 
ment for each input CSECT. When all of the necessary 
Linkage Editor control statements have been created and 
written out, CNTLSTMT passes control to the message fan- 
in routine. 

GETCHECK - Get and Check an Input Record: The get and 
check an input record routine is invoked by ESDPROC and 
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Figure 3-20. Module IDFCT Hierarchy of Routines 
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TXTPROC to read in the next sequential record from 
SYSIN and to check three fields of the record. The three 
fields checked are the deck ID, columns 73-76; card 
sequence number, columns 77-80; and card type, columns 
2-4. GETCHECK validates the deck ID field to ensure that 
the four-character deck identifier is the same on every card 
of the input object deck. It validates the card sequence 
number field to ensure that no input records are out of 
place or missing. Finally, GETCHECK checks the card type 
field to ensure that the card types themselves are in the 
correct sequence. That is,an ESD card must be followed by 
another ESD card or a TXT card; a TXT card must be foll- 
lowed by another TXT card or an END card; an END card 
must be followed by an ESD card (indicating that another 
FD program module follows) or an end-of-file indication. If 
no errors are detected in the three fields, GETCHECK 
returns control to the routine that called it. However, if 
GETCHECK does detect an error, it ceases processing 
immediately and passes control to the appropriate point in 
the message fan-in routine so that a descriptive error mes- 
sage may be written out to SYSPRINT. If an end-of-file 
indicator or an irrecoverable I/O error is encountered during 
the reading of SYSIN, GETCHECK does not retain control. 
These conditions are handled by the end-of-file subroutine 
of TXTPROC and the control synchronous I/O error rou- 
tine (CTLSYNER), respectively. GETCHECK uses the 
Queued Sequential Access Method (QSAM); the GET macro 
that is used to read in the records operates in the move 
mode. 


PUTCARD - Put Out A Card: The put out a card routine is 
invoked by ESDPROC, TXTPROC, and CNTLSTMT to 
write out a record to the SYSUT1 file. After the record has 
been put out successfully, PUTCARD returns control to the 
routine that called it. If an irrecoverable I/O error is 
encountered during the writing of a record, PUTCARD does 
not retain control. This error condition is handled by 
CTLSYNER. The PUTCARD access method is QSAM; the 
PUT macro that is used to write out the records operates in 
the move mode. 


CTLSYNER - Control Synchronous I/O Error: The control 
synchronous I/O error routine is invoked when an irrecover- 
able error is encountered during an input or output opera- 
tion. There are three entry points to the routine: 

SYNAD1, SYNAD2, and SYNAD3. These entry points are 
actually symbolic addresses that correspond to the three 
I/O files used by the Control step. SYNAD1 corresponds to 
SYSIN; SYNAD2, to SYSUT1; and SYNAD3, to 
SYSPRINT. The purpose of CTLSYNER is to determine 
the cause and type of error that occurred and to create an 
error message that explains the problem. The routine uses 
the SYNADAF macro to define the error and construct the 
error message. This macro examines the following data 
areas and records the pertinent information. 


@ The contents of the general registers 
@ The data event control block (DECB) 
@ The exceptional condition code | 

@ The status and sense indications 


After examining this data, the macro creates a descriptive 
error message that may be written out by either the diag- 
nostic writer routine or by CTLSYNER itself. When the 
error message has been created, CTLSYNER modifies the 
return address so that control will not be given to the 
instruction that immediately follows the GET or PUT 
macro instruction that encountered the I/O error. Rather, 
CTLSYNER gives control to the appropriate point in 
MSGFAN, if the SYSPRINT file is available, or to the con- 
trol end routine, if the SYSPRINT file has sustained an 
irrecoverable error. 


MSGFAN - Message Fan-In: The message fan-in routine 
may be invoked by any of the following routines: 
CNTLINIT, ESDPROC, TXTPROC, GETCHECK, 
CTLSYNER, and CNTLEND. MSGFAN consists of a series 
of branch and link (BAL) instructions, each of which corre- 
sponds to a message contained in the message module, 
IDFMO1. The routine may be entered at any one of these 
BAL instructions. The purpose of MSGFAN is to establish 
a binary number and place it in register 3. This binary num- 
ber equals the displacement between the start of MSGFAN 
and the point at which the entry to the routine was made. 
The number is used later by DIAGWTR for scanning a 
second-level index in IDFM0O1 to retrieve the variable detail 
line (s) of the message. When the binary number has been 
established in register 3, the routine transfers control to 
DIAGWTR. 


DIAG WTR - Diagnostic Writer: The diagnostic writer rou- 
tine is invoked by the message fan-in routine when all of 
the input record processing has been completed success- 
fully or when an error condition has been detected and the 
SYSPRINT file can be used. First, DIAGWTR issues a 
LOAD macro to bring the message module, IDFMO1, into 
main storage. Next, the routine moves the three variable 
characters of the message ID into the output area, 
OBJCARD. DIAGWTR then uses the binary number 
located in register 3, which is the number placed there by 
MSGFAN, to recover the detail line (s) of the message. 
Finally, the routine composes the rest of the header line, 
including the remainder of the message ID, then writes the 
header and detail lines out to the SYSPRINT file. At this 
point, DIAGWTR passes control to the control end routine, 
CNTLEND. 


CNTLEND - Control End: The control end routine is 
invoked by either DIAGWTR or WTORTN. It may be 
called when all of the input record processing has been 
completed successfully or when any type of error condition 
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has been encountered. The purpose of CNTLEND is to 
close the SYSIN, SYSUT1, and SYSPRINT files. When 
these files have been closed, the routine gives control to the 
operating system. 


OBJCARD - Card Image Storage Area: The format of the 
80-byte card image storage area is the same as the format of 
the ESD card described in Figure 3 in Part 3, Section 2, 
“Method of Operation.’ This storage area is used to con- 
tain ESD, TXT, and END cards during validation, as well as 
Linkage Editor control statements and the messages pro- 
duced by the diagnostic writer routine. 


Input DCB: The INPUT data control block describes the 
characteristics of the SYSIN file as follows: 


DDNAMESSYSIN 
LRECL=80 
MACRF=(GM) 
DSORG=PS 
EODAD=EOFRTN 
SYNAD=SYNADI1 
RECFM=FB 


Print DCB: The PRINT data control block describes the 
characteristics of the SYSPRINT file as follows: 


DDNAME=SYSPRINT 
MACRF=(PM) 
DSORG=PS 
SYNAD=SYNAD3 


Output DCB: The OUTPUT data control block describes 
the characteristics of the SYSUT 1 file as follows: 


DDNAMESSYSUT 1 
LRECL=80 
MACRF=(PM) 
RECFM=F 
DSORG=PS 
SYNAD=SYNAD2 
BLKSIZE=80 


IJLFCT Organization 


The phase IJLFCT is logically organized in nine routines, 
three DTFDI macros, and one device independent module 
(DIMOD), plus five 81-byte I/O and work areas. Figure 

3-21 represents the physical organization of IJLFCT. The 
logical flow of the nine routines is graphically represented in 
Charts DA1 through DA4 at the rear of this section. Figure 
3-22 illustrates the hierarchy of the routines within 

IJLFCT. The routine, macros, and the DIMOD are de- 
scribed in the following paragraphs. 


CNTLINIT - Control Initial: The control initial routine 
opens the SYSIPT, SYSPCH, and SYSLST files. Control 
passes automatically to the ESD processor routine unless 
one of the files fails to open. If one or more of the files 
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fails to open, the DOS Supervisor terminates the Control 
step and returns control to the DOS Job Control program. 


ESDPROC - ESD Processor: The ESD processor receives 
control from the control initial routine at the start of 
processing. It may also receive control from the TXT 
processor routine if multiple input modules are present. 
ESDPROC first invokes the get and check an input record 
routine (GETCHECK) to read in a card from SYSIPT and 
place it in one of two input/output buffers. The routine 
then validates the name field, type code, address field, and 
length field of each ESD item on the card. Next, it invokes 
GETCHECK to read in another card and place it in the 
other I/O buffer. Again, ESDPROC validates the ESD 
items, then transfers control to GETCHECK. This reading 
and validating process continues until the first TXT card is 
encountered. Each card that is read in is placed in the I/O 
buffer opposite from the most recently validated card. 
Also, ESDPROC maintains a count of the ESD items that it 
validates. When the first TXT card is encountered, one I/O 
buffer contains that TXT card and the other I/O buffer con- 
tains the last ESD card. At this point, ESDPROC gives con- 
trol to the create control statements routine (CNTLSTMT). 
If ESDPROC encounters an error during processing, it 

gives control to the appropriate point in the message fan-in 
routine (MSGFAN) so that a descriptive error message may 
be written out to the SYSLST file. 


CNTLSTMT - Create Control Statements: The create con- 
trol statements routine receives control from the ESD pro- 
cessor routine. By the time it gains control, all of the ESD 
items have been read in and validated, the count of ESD 
items has been completed, and the first TXT card has been 
encountered. Additionally, the last ESD card is contained 
in one I/O buffer and the first TXT card is contained in the 
other. The purpose of CNTLSTMT is to create and write 
out to SYSPCH the Linkage Editor control statements nec- 
essary to produce the overlay program that is executed in 
the Storage step. Also, since every ESD card (except the 
last one) is destroyed during the ESDPROC processing, 
CNTLSTMT must reconstruct these records and write them 
out to the SYSPCH file. CNTLSTMT creates the control 
statements and reconstructs the ESD card images in the I/O 
buffer that contains the last ESD card. Thus, the last ESD 
card is destroyed (but later reconstructed), whereas the first 
TXT card remains unaffected in the other I/O buffer. 
CNTLSTMT employs the put out a card routine 
(PUTCARD) for all of its writing operations. 

The first six statements created by CNTLSTMT are 
PHASE and INCLUDE statements for the object modules 
IJLFST, IJLFLOAD, and IJLFUPDT. The PHASE state- 
ments provide the Linkage Editor with phase names and 
origin points for the phases. The INCLUDE statements 
indicate to the Linkage Editor which object modules are to 
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Figure 3-21. Module IJLFCT Physical Organization 


be included for editing. The formats of the statements are 
as follows: 


WPHASE IJLFST,S 

bINCLUDE IJLFST 

BPHASE IJLFLOAD, S+144 

bINCLUDE IJLFLOAD 

BPHASE IJLFUPDT, S+144 

bINCLUDE IJLFUPDT 
Next, CNTLSTMT creates and writes out a series of PHASE 
and INCLUDE statements for the input FD program 
CSECTs. One PHASE statement and one INCLUDE state- 
ment is generated for each input CSECT. The format of 
these statements is as follows: 


BPHASE IJLFnnnn, +0 

WINCLUDE , (JLFnnnn) 

where nnnn is the number of an input CSECT that will 
become an overlay segment. 


(ESDPROC) 


Diagnostic Writer (DIAGWTR) 
Control End (CNTLEND) 
\/O Buffer 1 (OBJCARD1) 


When all the necessary Linkage Editor control statements 
have been created and written out, CNTLSTMT begins re- 
constructing the previously destroyed ESD card images 
and writing them out to SYSPCH. Since all of the ESD 
items were verified by ESDPROC, all of the data within 
those items (except the length field of the last ESD item) is 
predictable and can be reconstructed. Also, since 
ESDPROC maintained a count of the ESD items, 
CNTLSTMT can reconstruct the exact number of ESD 
items required. As soon as CNTLSTMT constructs an ESD 
card in the I/O buffer, it writes it out to SYSPCH, placing 
it behind the control statements, then reconstructs the next 
ESD card in the same I/O buffer. When the last ESD card 
has been reconstructed and written out, CNTLSTMT passes 
control to the TXT processor routine. 


TXTPROC - TXT Processor: The TXT processor routine 
receives control from the create control statements routine. 
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Figure 3-22. Module ISLFCT Hierarchy of Routines 


By the time it receives control, the first TXT card has 
already been placed in an I/O buffer. As previously ex- 
plained, this card is unaffected by the operation of 
CNTLSTMT. 

TXTPROC invokes PUTCARD to put out that first card, 
then alternately invokes GETCHECK and PUTCARD to 
read in and put out the remaining TXT cards. TXTPROC 
performs this reading and writing function until it encoun- 
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tersan END card. At that point, it puts out the END card 
and reads the next record. If the next record read is the 
end-of-file indication, the routine passes control to the mes- 
sage fan-in routine for the construction of a message indi- 
cating successful completion. However, if the next record is 
an ESD card, then multiple input object decks are present. 
In this case, TXTPROC sets the multiple object deck indi- 
cator (NEWJOB) to one and the address counter 
(ADDRCTR) to zero, then passes control to the ESD 
processor. On the other hand, if the next record read is 
neither an end-of-file indication nor an ESD card, then an 
error condition exists. This error is detectable by 
GETCHECK. If it occurs, TXTPROC does not regain con- 
trol from GETCHECK. Rather, GETCHECK passes control 
to the appropriate point in the message fan-in routine so 
that a descriptive error message may be written out to 
SYSLST. 


GETCHECK - Get and Check an Input Record: The get and 
check an input record routine is invoked by ESDPROC and 
TXTPROC to read in the next sequential record from 
SYSIPT and to check three fields of the record. The three 
fields checked are deck ID, columns 73-76; card sequence 
number, columns 77-80; and card type, columns 2-4. 
GETCHECK validates the deck ID field to ensure that the 
four-character deck identifier is the same on every card of 
the input object deck. It validates the card sequence num- 
ber field to ensure that no input records are out of place or 
missing. Finally, GETCHECK checks the card type field to 
ensure that the card types themselves are in the correct 
sequence. That is,an ESD card must be followed by 
another ESD card or a TXT card; a TXT card must be fol- 
lowed by another TXT card of an END card; an END card 
must be followed by an ESD card (indicating that another 
FD program module follows) or an end-of-file indication. 
If no errors are detected in the three fields, GETCHECK 
returns control to the routine that called it. However, if 
GETCHECK does detect an error, it ceases processing 
immediately and passes control to the appropriate point 

in the message fan-in routine so that a descriptive error 
message may be written out to SYSLST. If an end-of-file 
indication is encountered during the reading of SYSIPT, 
GETCHECK does not retain control; this condition is 
handled by the end-of-file subroutine of TXTPROC. 
GETCHECK uses the Device Independent (DI) access 
method for all data retrieval. 


Note: GETCHECK can process both 80- and 81- character 
input records. When it discovers that an 81-character record 
has been read, it deletes the control character and processes 
the record as a standard 80-character record. Through this 
capability, the Control step of the FD utility can receive 
inputs from tape and disk, as well as from a card reader. 


PUTCARD - Put Out a Card: The put out a card routine is 
invoked by CNTLSTMT and TXTPROC to write out a card 
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image to the SYSPCH file. It may also be invoked by the 
diagnostic writer routine (DIAGWTR) to write out a record 
to the SYSLST file. After the card image or record has 
been put out successfully, PUTCARD returns control to the 
routine that called it. PUTCARD uses the DI access method 
for all data writing. 


MSGFAN - Message Fan-In: The message fan-in routine 
may be invoked by ESDPROC, GETCHECK, and 
CNTLEND. MSGFAN consists of a series of branch and link 
(BAL) instructions, each of which corresponds to a mes- 
sage contained in the message module, IJLFMO1. The rou- 
tine may be entered at any one of these BAL instructions. 
The purpose of MSGFAN is to establish a binary number 
and place it in register 3. This binary number equals the 
displacement between the start of MSGFAN and the point 
at which the entry to the routine is made. The number is 
used later by the diagnostic writer routine for scanning an 
index in IJLFMO1 to retrieve the variable detail line(s) of 
the message. When the binary number has been established 
in register 3, the routine transfers control to the diagnos- 
tic writer routine. 


DIAGWTR - Diagnostic Writer: The diagnostic writer rou- 
tine is invoked by the message fan-in routine when all of the 
input record processing has been completed successfully or 
when an error has been detected in an input record. First, 
DIAGWTR issues a LOAD macro to bring the message mod- 
ule, IJLFMO1, into main storage. Next, the routine moves 
the three variable characters of the message ID into the out- 
put area. DIAGWTR then uses the binary number located 
in register 3, which is the number placed there by 
MSGFAN, to recover the detail line (s) of the message. 
Finally, the routine composes the rest of the header line, 
including the remainder of the message ID, then writes the 
header and detail lines out to the SYSLST file. At this 
point, DIAGWTR passes control to the control end routine. 


CNTLEND - Control End: The control end routine is 
invoked by the diagnostic writer routine. It may be called 
when all of the input record processing has been completed 
successfully or when an error has been discovered in an 
input record. The purpose of CNTLEND is to close the 
SYSIPT , SYSPCH, and SYSLST files. When these files have 
been closed, the routine gives control to the operating 
system. 


SYSIPT DTFDI Macro: The DTFDI macro for the system 
input file, SYSIPT, specifies the following operands: 


DEVADDRS=SYSIPT MODNAMESIJJFCBIC 


EOFADDR=EOFRTN RECSIZE=80 
IOAREA1=INAREA1 WLRERR=WLREC 
IOAREA2=INAREA2 SEPASMB=NO 


IOREG=(9) ERROPT=IGNORE 


SYSPCH DTFDI Macro: The DTFDI macro for the system 
output file, SYSPCH, specifies the following operands: 


DEVADDR=SYSPCH 
IOAREA1=WKAREA 
MODNAME=IJJFCBIC 
ERROPT=IGNORE 
RECSIZE=8 1 
SEPASMB=NO 


SYSLST DTFDI Macro: The DTFDI macro for the system 
print file, SYSLST, specifies the following operands: 


DEVADDR=SYSLST 
IOAREA1=PRNTAREA 
MODNAME=IJJFCBIC 
RECSIZE=8 1 
SEPASMB=NO 
ERROPT=IGNORE 


DIMOD: The characteristics of the device independent 
module (DIMOD) are specified through the use of the 
DIMOD macro. The name of this module within IJLFCT is 
IJJFCBIC. Its characteristics are defined as follows: 


IOAREA2=YES 
SEPASMB=NO 
TYPEFILE=OUTPUT 


Additional information about the DTFDI and DIMOD mac- 
ros is contained in the manual JBM System/360 Disk Oper- 
ating System Supervisor and Input/Output Macros, Order 
Number GC24-5037. 


Linkage Editor Step Organization 


The OS and DOS versions of the FD utility employ the 
OS and DOS Linkage Editor programs in their respective 
Linkage Editor steps. The inputs and outputs from the 
Linkage Editor are described in Part 3, Section 2. 
“Method of Operation.” A description of the OS and 
DOS Linkage Editors’ organization is beyond the scope of 
this manual. However, complete Linkage Editor informa- 
tion may be found in the following publications: 


® OS Version: JBM System/360 Operating System Linkage 
Editor and Loader, Order Number GC28-6538; 
IBM System/360 Operating System Linkage Editor |F | 
Program Logic Manual, Order Number GY28-6610 


@ DOS Version: [BM System/360 Disk Operating System: 
System Control and System Service Programs, Order 


Number GC24-5036; 
IBM System/360 Disk Operating System Linkage Editor 


Program Logic Manual, Order Number GY24-5080 
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Storage Step Organization 


The overlay program that is executed in the Storage step is 
created by the Linkage Editor in the previous step. This 
program consists of the linkage edited object module 
IDFST (OS) or ISLFST, IJLFLOAD, and IJLFUPDT 
(DOS) and the overlay segments containing the FD pro- 
grams. The organization of the modules is dissimilar 
enough to merit a separate discussion of each. These mod- 
ules are described in the following paragraphs. 


IDFST Organization 


The load module IDFST is logically organized in nine rou- 
tines, two DCBs, and two Linkage-Editor-created tables. 
Furthermore, if the PARM facility of JCL is employed, 
IDFST may construct a replacement table. Since the 
generation and composition of the two Linkage-Editor- 
created tables were discussed in Part 3, Section 2, “Method 
of Operation,” no more discussion of these tables is con- 
tained in this section. Figure 3-23 represents the physical 
organization of IDFST. The logical flow of the nine rou- 
tines is graphically represented in Charts OB1 through OB4 
at the rear of this section. Figure 3-24 illustrates the hierar- 
chy of the routines within IDFST. 


STGINIT - Storage Initial: The storage initial routine opens 
and tests the opening of the SYSLIB (user’s library) and 
SYSPRINT files. Control passes automatically to the 
PARM processor routine unless one of the files fails to open 
properly. If the opening of SYSLIB fails, STGINIT gives 
control to the appropriate point in the message fan-in rou- 
tine (MSGFAN) so that a descriptive error message may be 
written out to SYSPRINT. If the opening of SYSPRINT 
fails, STGINIT writes a message out to the operator console, 
then transfers control to the storage end routine. 


PARMPROC - PARM Processor: The PARM processor rou- 
tine receives control from STGINIT at the start of proces- 
sing. The purpose of PARMPROC is to validate the param- 
eters that were passed from the JCL and to set an indicator 
(PARMSW) to tell the new member routine (NEWMEM) 
whether a replacement table should be constructed. If any 
of the parameters are invalid, PARMPROC ceases processing 
immediately and gives control to the appropriate point in 
MSGFAN so that a descriptive error message may be writ- 
ten out to SYSPRINT. If the user has elected not to use the 
parameter feature, PARMPROC leaves PARMSW set to zero 
(the value at which it was initialized) and passes control to 
NEWMEM. If the user has specified REPLACE=ALL, 
PARMPROC sets PARMSW to one, then passes control to 
NEWMEM. If the user has specified a partial replacement, 
PARMPROC sets PARMSW to two, then passes control to 
NEWMEM. Only this value of PARMSW (two) causes 
NEWMEM to create a replacement table if it encounters any 
duplicate FD programs. A duplicate FD program is one that 
bears the name of an FD program that is already present in 
the user’s library. 
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NEWMEM - New Member: The new member routine 
receives control from the PARM processor routine. The 
purpose of NEWMEM is to create the new library members 
and place them in the user’s FD program library. NEWMEM 
first invokes the segment processor routine (SEGPROC) 

to load the first overlay segment, IDF1000, into main stor- 
age. It then examines the count subfield of the KUPBs 
within the segment and writes the 476-byte unpacked pro- 
gram block field out to the user’s library. When all of the 
KUPBs in the segment have been examined and selectively 
written out, NEWMEM again invokes SEGPROC to load 
the next sequential overlay segment. The routine con- 
tinues this loading, examining, and writing process until 

it encounters the end-of-form indication. At that point, 
NEWMEM stores the last unpacked program block of the 
FD program, then issues the appropriate form of the STOW 
macro to assign the new member’s name. 

NEWMEM’s next action depends upon the return code 
from the STOW operation. If the STOW was successful, 
NEWMEM begins processing the next FD program. How- 
ever, if the STOW was not successful because the FD pro- 
gram was a duplicate, NEWMEM may perform one of the 
following functions: 


@ If the user has specified REPLACE, NEWMEM replaces 
the old member with the new member. 


@ If the user has specified a partial replacement, NEWMEM 
creates a replacement table from the input parameter 
list, searches the table for the name of the new member, 
and replaces the old member with the new member if the 
name is found in the replacement table. If the name is 
not found in the replacement table, NEWMEM stores the 
new member under a temporary name, if one is available, 
or does not store it at all. 


@ If the user has not specified any replacement parameters, 
NEWMEM stores the new member under a temporary 
name, if one is available, or does not store it at all. 


If the STOW was unsuccessful because of a stow error or a 
DASD space error, NEWMEM passes control to the appro- 
priate point in the message fan-in routine so that a descrip- 
tive error message may be written out to SYSPRINT. 

NEWMEM resumes processing with the next KUPB in the 
segment, if one is available, or it invokes SEGPROC to load 
the next segment. The next KUPB encountered is the first 
KUPB of the next FD program. The routine processes the 
new FD program and all other new FD programs in this 
manner until it encounters the end-of-assembly indicator. 
It then passes control to the diagnostic writer routine 
(DIAGWTR). If NEWMEM discovers an error in the count 
subfield of a KUPB, it ceases processing immediately and 
gives control to the appropriate point in MSGFAN so that 
a descriptive error message may be written out to 
SYSPRINT. 


SEGPROC - Segment Processor: The segment processor 
routine is invoked by the new member routine to load an 
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Figure 3-23. Module IDFST Physical Organization 


overlay segment into main storage. SEGPROC first 

sets the status indicator in the SEGT AB entry of the 
previously called segment to 11, increments the “to” seg- 
ment number in ENTAB by one, and sets the “‘previous cal- 
ler” field in ENTAB to zero. It then issues a SEGWT 
supervisor call (SVC 37) to read in the segment. When the 
input operation is complete, SEGPROC returns control to 
NEWMEM. Ifa request is made for a segment that exceeds 
the range of the available segments, SEGPROC passes con- 
trol to the appropriate point in MSGFAN so that a descrip- 
tive error message may be written out to SYSPRINT. 


SYNAD1 and SYNAD2 - Control Synchronous 1/O Error: 
One of the control synchronous I/O error routines is 
invoked when an irrecoverable error is encountered during 
an input or output operation. These routines actually cor- 
respond to the two I/O files used by the Storage step. 
SYNADI1 corresponds to SYSPRINT; SYNAD2 corresponds 
to SYSLIB. The purpose of these routines is to determine 
the cause and type of error that occurred and to create an 
error message that explains the problem. The routines use 
the SYNADAF macro to define the error and construct the 
error message. This macro examines the following data 
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Figure 3-24. Module IDFST Hierarchy of Routines 


areas and records the pertinent information. 
@ The contents of the general registers 

@ The data event control block (DECB) 

@ The exceptional condition code 


@ The status and sense indications 


After examining this data, the macro creates a descriptive 
error message that may be written out by either the diag- 
nostic writer routine for a SYSLIB error or by SYNAD1 
itself fora SYSPRINT error. After the message has been 
issued, control is passed to the storage end routine. 
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MSGFAWN - Message Fan-In: The message fan-in routine 
may be invoked by any of the following routines: 
STGINIT, PARMPROC, NEWMEM, SEGPROC, SYNAD2, 
and STGEND. MSGFAN consists of a series of branch and 
link (BAL) instructions, each of which corresponds to a 
message contained in the message module, IDFM0O1. The 
routine may be entered at any one of these BAL instruc- 
tions. The purpose of MSGFAN is to establish a binary 
number and place it in register 3. This binary number 
equals the displacement between the start of MSGFAN and 
the point at which the entry to the routine was made. The 
number is used later by DIAGWTR for scanning a second- 
level index in IDFMO1 to retrieve the variable detail line(s) 
of the message. When the binary number has been estab- 
lished in register 3, the routine transfers control to 
DIAGWTR. 


DIAGWTR - Diagnostic Writer: The diagnostic writer rou- 
tine is invoked by the message fan-in routine when all of the 
overlay segment processing is complete or when an error 
condition is detected and the SYSPRINT file can be used. 
First, DIAGWTR issues a LOAD macro to bring the message 
module, IDFMO1, into main storage. Next, the routine 
moves the three variable characters of the message ID into 
the output area, OUTPUT. DIAGWTR then uses the 

binary number located in register 3, which is the number 
placed there by MSGFAN, to recover the detail line(s) of 
the message. Finally, the routine composes the rest of the 
header line, including the remainder of the message ID, then 
writes the header and detail lines out to the SYSPRINT file. 
At this point, DIAGWTR checks to see if processing should 
continue. If so, it passes control to the proper routine for 
continued processing; if not, DIAGWTR passes control to 
the storage end routine. 


STGEND - Storage End: The storage end routine is invoked 
by either DIAGWTR or WTORTN. It may be called when 
all of the overlay segment processing has been completed 
successfully or when any type of error condition has been 
encountered. The purpose of STGEND is to close the 
SYSLIB and SYSPRINT files. When these files have been 
closed, the routine gives control to the operating system. 


Output DCB: The OUTPUT data control block describes 
the characteristics of the SYSLIB file as follows: 


DDNAMESSYSLIB 
LRECL=476 
BLKSIZE=476 
MACRF=(W) 
DSORG=PO 
SYNAD=SYNAD2 
RECFM=F 


PRINT DCB: The PRINT data control block describes the 
characteristics of the SYSPRINT file as follows: 


DDNAME=SYSPRINT 
MACRF=(PM) 


DSORG=PS 
SYNAD=SYNAD1 


REPLTAB - Replacement Table: The replacement table is 
constructed by the PARM processor routine if the user has 
employed the JCL PARM feature. The format of 
REPLTAB is illustrated in Figure 3-25. 


Eight 
Bytes 


a 


Figure 3-25. OS REPLTAB Format 


IJLFST Organization 


The phase IJLFST is logically organized in seven routines, 
two DTFDI macros, and one device independent module 
(DIMOD). Figure 3-26 represents the physical organiza- 
tion of IJILFST. The logical flow of the seven routines is 
graphically represented in Charts DB1 and DB2 at the rear 
of this section. Figure 3-27 illustrates the hierarchy of the 
routines within IJLFST. The routines, macros, and the 
DIMOD are described in the following paragraphs. 


OPEN - Open Files: The open files routine opens the 
SYSIPT and SYSLST files. Control passes automatically to 
the get and process control cards routine unless one of the 
files fails to open. If one or both of the files fails to open, 
the DOS Supervisor terminates the Storage step and returns 
control to the DOS Job Control program. 


GET - Get and Process Control Cards: The get and process 
control cards routine receives control from OPEN at the 
start of processing. First, it invokes GETCARD to read in 
and validate a control card. It then determines which oper- 
and the user has specified (DEVICE=, OPTION=, 
RPLACE=, or RPLACE). After determining the operand, 
GET validates the operand type to ensure that the control 
card has been coded correctly. 

If the operand is DEVICE=, the operand type must be 
either 2311 or 2314; if neither of these is specified, GET 
passes control to the error exit routine, ERREXT. If either 
2311 or 2314 is specified, GET sets the indicator in the first 
half-word of the replacement table, RPLTAB, to the appro- 
priate value, then reads in another card for processing. 

If the operand is OPTION=, the operand type must be 
UPDATE, LOAD, or LOADFST; if none of these is speci- 
fied, GET passes control to ERREXT. Ifa valid operand 


type is specified, GET sets the indicator in the second half- 
word of RPLTAB to the appropriate value, then reads in 
another card for processing. 

IF the operand is RPLACE=, GET increments the replace 
card counter by one and checks to see whether the total of 
replace cards has exceeded 20. If the total has exceeded 20, 
GET passes control to ERREXT; if not, it saves the speci- 
fied name in the next available eight-byte location in 
RPLTAB, then reads in another card for processing. 

If the operand is RPLACE, GET inserts a X‘FF’ in the 
location RPLTAB+4 to indicate that the REPLACE ALL 
function was specified. It then reads in another card for 
processing. GET continues reading and processing the con- 
trol cards until it encounters an end-of-file indication, at 
which time control is passed to the end-of-file routine, 
EOFRTN. 


GETCARD - Get and Validate a Control Card: The get and 
validate a control card routine is invoked by GET to read in 
a card from SYSIPT and validate it. The validation consists 
of checking the first three columns for “‘//%” and ensuring 
that a valid operand is present. If the card is improperly 
coded, GETCARD passes control to ERREXT. Otherwise, 
it returns control to GET. 


ERREXT - Common Error Exit: The common error exit 
routine may be invoked by either GET or GETCARD. It is 
invoked if any field of a control card is invalid. ERREXT 
first sets the error flag and prints out the message 
“INCORRECT - JOB TERMINATED,” then closes the 
SYSLST file and passes control to the flush cards routine, 
FLSHCARD. 


ERREXTI - Special Error Exit: The special error exit rou- 
tine is invoked by GET if GET detects more than 20 con- 
trol cards with the operand “RPLACE=”. ERREXT1 first 
sets the error flag and prints out the message “NUMBER OF 
REPLACE CARDS EXCEEDS TWENTY - JOB TERMI- 
NATED,” then closes the SYSLST file and passes control to 
FLSHCARD. 


FLSHCARD - Flush Cards: The flush cards routine receives 
control from ERREXT or ERREXT1 when an error has 
been encountered. Its function is to read in cards from the 
SYSIPT file until the end-of-file indication is encountered. 
At that point, the DOS Supervisor passes control to 
EOFRTN. 


EOFRTN - End-of-File: The end-of-file routine is invoked 
by the DOS Supervisor when the end-of-file indication is 
encountered on the SYSIPT file. When EOFRTN first 
gains control, it checks the error flag to see if an error has 
occurred. If so, it closes the SYSIPT file and exits to the 
operating system. If not, EOFRTN saves RPLTAB at the 
end of the user’s partition and closes the SYSIPT and 
SYSLST files. It then checks to see which option the user 
has specified. If the user has specified LOADFST or 
UPDATE, EOFRTN fetches and passes control to 
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ISLFUPDT. If the user has specified LOAD, EOFRTN 
fetches and passes control to ISLFLOAD. 


SYSIPT DTFDI Macro: The DTFDI macro for the system 
input file, SYSIPT, specifies the following operands: 


DEVADDR=SYSIPT 
EOFADDR=EOFRTN 
IJOAREA1=RDAREA 
MODNAME=INMOD 
RECSIZE=80 
ERROPT=IGNORE 
SEPASM B=NO 


SYSLST DTFDI Macro: The DTFDI macro for the system 
print file, SYSLST, specifies the following operands: 


DEVADDR=SYSLST 
IOAREA1=ERRMSG 
MODNAME=INMOD 
RECSIZE=121 
SEPASMB=NO 
ERROPT=IGNORE 


DIMOD: The characteristics of the device independent 
module (DIMOD) are specified through the use of the 
DIMOD macro. The name of this module within IJLFST 
is INMOD. Its characteristics are defined as follows: 


SEPASMB=NO 
TYPEFLE=OUTPUT 


Additional information about the DTFDI and DIMOD mac- 
ros is contained in the manual JBM System/360 Disk Opera- 
ting System Supervisor and Input/Output Macros, Order 
Number GC24-5037. 


IJLFLOAD Organization 


The phase IJLFLOAD is logically organized in seven rou- 
tines, one DTFDI macro, one DTFIS macro, one device 
independent module (DIMOD), and one ISAM module 
(ISMOD). Figure 3-28 represents the physical organization 
of ISLFLOAD. The logical flow of the seven routines is 
graphically represented in charts DC1 and DC2 at the rear 
of this section. Figure 3-29 represents the hierarchy of the 
routines within IJLFLOAD. The routines, macros, and 
modules are described in the following paragraphs. 


CALLOAD - Load Initial: The load initial routine opens 
the IJFDLIB (user’s library) and SYSLST files. If one or 
both of the files fails to open properly, the DOS Supervisor 
terminates IJLFLOAD and returns control to the DOS Job 
Control program. However, if the files do open properly, 
CALLOAD invokes the load overlay phases routine, 
LOADRTN, to load the first overlay phase. It saves the 
name and count subfields of the first KUPB in the phase, 
then transfers control to the validate records routine, 
RCDCHK. 


RCDCHK - Validate Records: The validate records routine 
receives control from CALLOAD after the first overlay 
phase has been loaded. RCDCHK validates the name and 
count subfields of the first KUPB in the overlay phase, then 
invokes the ISAM put routine, ISMPUT, to write out the 
476-byte unpacked program block field to the user’s 
library, together with the 10-byte key. It processes the sec- 
ond and third KUPBs in the same manner. When the three 
KUPBs in an overlay phase have been processed, RCDCHK 
invokes LOADRTN to load the next sequential phase. 
RCDCHK continues this reading, validating, and writing 
process until it encounters an end-of-assembly indication. 
At that point, it transfers control to the message fan-in 
routine, MSGFAN, to write out a message indicating the 
successful completion of IILFLOAD. If RCDCHK dis- 
covers an error in the name or count subfield of any KUPB, 
it transfers control to the appropriate point in MSGFAN so 
that a descriptive error message may be written out. 


LOADRTN - Load Overlay Phases: The load overlay phases 
routine is invoked by CALLOAD and RCDCHK to load an 
overlay phase into main storage from the core image library. 
LOADRTN uses the LOAD macro to read in the phase. 
When the input operation is complete, LOADRTN returns 
control to the calling routine. 


ISMPUT - ISAM Put: The ISAM put routine is invoked by 
RCDCHK to put out a 476-byte unpacked program block 
and a 10-byte key to the user’s library, IJFDLIB. Before 
ISMPUT writes out any records, it initializes the data set 
index areas by issuing a SETFL macro. It then attempts to 
write out the record. If the attempt is successful, ISMPUT 
returns control to RCDCHK. If the attempt is unsuccess- 
ful because of a DASD error, wrong length record error, or 
undetermined error, ISMPUT again attempts to write out © 
the record. If this attempt is successful, the routine returns 
control to RCDCHK;; if it is unsuccessful, ISMPUT passes 
control to the appropriate point in MSGFAN so that a 
descriptive error message may be written out. Similarly, if 
the original attempt to write out the record is unsuccess- 
ful for any reason other than those stated above ISMPUT 
passes control to MSGFAN. 


MSGFAN - Message Fan-In: The message fan-in routine 
may be invoked by RCDCHK or ISMPUT. MSGFAN con- 
sists of a series of branch and link (BAL) instructions, each 
of which corresponds to a message contained in the message 
module, IJLFMO1. The routine may be entered at any one 
of these BAL instructions. The purpose of MSGFAN is to 
establish a binary number and place it in register 3. This 
binary number equals the displacement between the start of 
MSGFAN and the point at which the entry to the routine is 
made. The number is used later by the diagnostic writer 
routine for scanning an index in IJLFMO1 to retrieve the 
required message. When the binary number has been es- 
tablished in register 3, the routine transfers control to the 
diagnostic writer routine. 
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Figure 3-28. Module IJLFLOAD Physical Organization 
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DIAGWTR - Diagnostic Writer: The diagnostic writer rou- 
tine is invoked by the message fan-in routine when all of 
the overlay phase processing has been completed success- 
fully or when an error has been detected by RCDCHK or 
ISMPUT. First, DIAGWTR uses the value in register 3 to 
compute the proper offset in IJLFMO1. Next, it issues a 
load macro to bring IJLFMO1 into main storage, then moves 
the appropriate message into the output area. Finally, it 
writes the message out to the SYSLST file. When the out- 
put operation is complete, DIAGWTR passes control to the 
end-of-job routine, EOJRTN. 


EOJRTN - End-of-Job: The end-of-job routine receives con- 
trol from DIAGWTR. Its purpose is to close the IJFDLIB 
and SYSLST files. First, EOJRTN issues an ENDFL macro 
to write out an EOF indication to IJFDLIB. If this action 
causes the prime data area to overflow, EOJRTN transfers 
control to MSGFAN. If not, EOJRTN closes the two files 
and exits to the operating system. 


IJFEDLIB DTFIS Macro: The DTFIS macro for the user’s 
library file, IIFDLIB, specifies the following operands: 


DSKXTNT=3 DEVICE=2311 
IOROUT=LOAD ERREXT=YES 

KEY LEN=10 HINDEX=2311 
NRECDS=1 IOAREAL=ISAMAREA 
RECFORM=FIXUNB MODNAME=LOADMOD 
RECSIZE=476 WORKL=WKAREA 
CYLOFL=8 


SYSLST DTFDI Macro: The DTFDI macro for the system 
print file, SYSLST, specifies the following operands: 


DEVADDR=SYSLST 
IOAREAI=ERRMSG 
MODNAME=OUTMOD 
RECSIZE=121 
SEPASM B=NO 
ERROPT=IGNORE 


ISMOD: The characteristics of the ISAM module (ISMOD) 
are specified through the use of the ISMOD macro. The 
name of this module within IILFLOAD is LOADMOD. Its 
characteristics are defined as follows: 


ERREXT=YES 
IOROUT=LOAD 
SEPASMB=NO 


DIMOD: The characteristics of the device independent 
module (DIMOD) are specified through the use of the 
DIMOD macro. The name of this module within 
IJLFLOAD is OUTMOD. Its characteristics are defined as 
follows: 


SEPASMB=NO 
TYPEFLE=OUTPUT 


IJLFUPDT Organization 


The phase IJLFUPDT is logically organized in nine routines, 
one DTFIS macro, one DTFDI macro, one ISAM module 
(ISMOD), and one device independent module (DIMOD). 
Figure 3-30 represents the physical organization of 
IJLFUPDT. The logical flow of the nine routines is graph- 
ically represented in charts DD1 through DD4 at the rear of 
this section. Figure 3-31 represents the hierarchy of the 
routines within IJLFUPDT. The routines, macros, and 
modules are described in the following paragraphs. How- 
ever, before the routines are entered, IILFUPDT examines 
RPLTAB to determine which device type was specified. If 
the device type is 2311, control is passed immediately to 
the update initial routine, CALLOAD. However, if the 
device type is 2314, IJLFUPDT modifies the IJFDLIB 
DTFIS macro to indicate 2314. Control is then passed to 
CALLOAD. 


CALLOAD - Update Initial: The update initial routine 
opens the IJFDLIB (user’s library) and SYSLST files. If 
one or both of the files fails to open properly, the DOS 
Supervisor terminates IJLFUPDT and returns control to the 
DOS Job Control program. However, if the files do open 
properly, CALLOAD invokes the load overlay phases rou- 
tine. LOADRTN, to load the first available overlay phase. 

It saves the name and count subfields of the first KUPB in 
the phase, then transfers control to the validate records rou- 
tine, RCDCHK. 


RCDCHK - Validate Records: The validate records routine 
receives control from CALLOAD after the first available 
overlay phase has been loaded. The purpose of RCDCHK 
is to create new library members and to place them in the 
user’s FD program library. RCDCHK validates the name 
and count subfields of the first KUPB in the overlay phase, 
then invokes the ISAM put routine, ISMPUT, to write out 
the 476-byte unpacked program block and 10-byte key to 
the user’s library. If the routine discovers an error in either 
of the subfields, it invokes MSGFAN to print out a descrip- 
tive error message, then passes control to the flush FD pro- 
gram routine, FLUSH. RCDCHK processes the second and 
third KUPBs in the same manner as the first. When the 
three KUPBs of an overlay phase have been processed, 
RCDCHK invokes LOADRTN to load the next available 
phase. It then processes the KUPBs within that phase. 
RCDCHK continues processing overlay phases in this man- 
ner until it reaches the end of the FD program. At that 
point, it prints out a message stating that the program has 
been stored, then resumes processing with the next FD pro- 
gram. When all of the FD programs have been processed, 
RCDCHK invokes MSGFAN to write out a message indi- 
cating the successful completion of the Storage step, then 
transfers control to the end-of-job routine, EOJRTN. 
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Figure 3-30. Module IILFUPDT Physical Organization 


LOADRTN - Load Overlay Phases: The load overlay phases 
routine may be invoked by CALLOAD, RCDCHK, and 
FLUSH. The purpose of LOADRTN is to load an overlay 
phase into main storage. It issues a LOAD macro to bring 
in the phase, then increments the phase name operand that 
will be used to retrieve the next sequential overlay phase in 
the next pass through LOADRTN. Finally, it returns con- 
trol to the calling program. 


ISMPUT - ISAM Put: The ISAM put routine is invoked by 
RCDCHK to write out a keyed record on IJFDLIB. In addi- 
tion to the initial output operation, ISMPUT contains four 
subroutines that are used to ensure that the record is writ- 
ten out properly. ISMPUT first moves the record to be 
stored into the output area. It writes out the record, waits 
for the output operation to end, then checks to see if the 
record was a duplicate. If the record was a duplicate, it 
transfers control to the DUPRTN subroutine; if not, it 
transfers control to the ERRRTN subroutine. 


@ ERRRTN - The purpose of ERRRTN is to ensure that 
the record was written out without error. First, it checks 
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to see if there was a DASD error or a wrong length rec- 
ord error. If there was an error, ERRRTN attempts the 
output operation again and checks the results. If the 
operation is successful this time, ERRRTN transfers con- 
trol to the DATAOK subroutine; if not, it invokes 
MSGFAN to print out an error message, then transfers 
control to EOJRTN. If neither of the above mentioned 
errors has occurred, ERRRTN checks to see if an EOF 
was written out, if no output record was found, or if 

the overflow area was full. If one of these errors has 
occurred, ERRRTN invokes MSGFAN to write out an 
error message, then transfers control to EOJRTN. Other- 
wise, if ERRRTN does not detect any of these errors, it 
transfers control to the DATAOK subroutine. 


DATAOK - The DATAOK subroutine receives control 
from either ERRRTN or RPLCDUP. It checks to see if 
a temporary name was assigned to the FD program cur- 
rently being processed and, if so, whether the user has 
been notified. If a temporary name has been assigned 
and the user has not been notified, DATAOK invokes 
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MSGFAN to write out the information message, then 
returns control to RCDCHK. If no temporary name was 
assigned, DATAOK simply returns control to RCDCHK. 


@ DUPRTN - The DUPRTN subroutine receives control if 
the record that ISMPUT is trying to write out is part of a 
duplicate FD program. If the user has specified a 
LOADFST operation, or if he has specified RPLACE, or 
if the FD program’s name is in the replacement table, 
DUPRTN transfers control to the RPLCDUP subroutine. 
If none of these conditions apply, DUPRTN prepares the 
record for storage under a temporary name, then trans- 
fers control to the start of ISMPUT so that the record 
may be stored. However, if no temporary names are 
available, DUPRTN prints out a message stating that fact 
and transfers control to FLUSH. 


@ RPLCDUP - The RPLCDUP subroutine receives control 
from DUPRTN when a duplicate record is to be replaced 
in IJFDLIB. It reads in the record to be replaced and 
writes out the new record in its place. It then checks to 
see if the record was written out properly. If it was not, 
RPLCDUP transfers control to ERRRTN. If the record 
was written out properly, RPLCDUP transfers control to 
DAT AOK. 


UPDTNM - Update Name: The update name routine may 
be invoked by RCDCHK and ISMPUT. The purpose of 
UPDTNM is to increment the temporary name number field 
by one. After it has accomplished this task, it returns con- 
trol to the calling routine. 


FLUSH - Flush FD Program: The flush FD program rou- 
tine receives control from RCDCHK when that routine dis- 
covers an error in a KUPB. FLUSH simply reads in the 
erroneous FD program’s KUPBs until it encounters the next 
FD program or the end-of-assembly indication. If it en- 
counters the end-of-assembly indication, it transfers con- 
trol to EOJRTN; otherwise, it transfers control to the label 
SAVENM1 in CALLOAD. 


MSGFAN - Message Fan-In: The message fan-in routine 
may be invoked by RCDCHK, ISMPUT, and EOJRTN. 
MSGFAN consists of a series of branch and link (BAL) 
instructions, each of which corresponds to a message con- 
tained in the message module, IJLFMO1. The routine may 
be entered at any one of these BAL instructions. The pur- 
pose of MSGFAN is to establish a binary number and to 
place it in register 3. This binary number equals the dis- 
placement between the start of MSGFAN and the point at 
which the entry to the routine is made. The number is used 
later by the diagnostic writer routine for scanning an index 
in IJLFMO1 to retrieve the required message. When the 
binary number has been established in register 3, MSGFAN 
transfers control to the diagnostic writer routine. 
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DIAGWTR - Diagnostic Writer: The diagnostic writer rou- 
tine is invoked by the message fan-in routine when all of 
the overlay phase processing has been completed success- 
fully or when an error has been detected by RCDCHK or 
ISMPUT. First, DIAGWTR issues a LOAD macro to bring 
IJLFMO1 into main storage. Next, it uses the value in 
register 3 to compute the proper offset in IJLFMO1, then 
moves the message into the output area. If the message 
needs the FD program name or temporary name inserted 
into its text, DIAGWTR inserts it. It then writes out the 
message to the SYSLST file and returns control to the rou- 
tine that invoked MSGFAN. 


EOJRTN - End-of-Job: The end-of-job routine may be 
invoked by RCDCHK when all of the overlay phases have 
been processed correctly, or by ISMPUT if that routine 
encounters an error. EOJRTN prints out a message stating 
that the Storage step has been completed, then closes the 
IJFDLIB and SYSLST files. Finally, it exits to the opera- 
ting system. 


IJFDLIB DTFIS Macro: The DTFIS macro for the user’s 
library file, IJFDLIB, specifies the following operands: 


DSKXTNT=3 HINDEX=2311 
IOROUT=ADDRTR JOAREAL=RWKAREA 
KEYLEN=10 IOAREAR=RWKAREA 
NRECDS=1 IOSIZE=560 
RECFORM=FIXUNB KEYARG=KEYFLD 
RECSIZE=476 MODNAME=UPDTMOD 
CYLOFL=8 TYPEFLE=RANDOM 
DEVICE=2311 WORKL=WKAREA 
ERREXT=YES WORKR=WKAREA 


SYSLST DTFDI Macro: The DTFDI macro for the system 
print file, SYSLST, specifies the following operands: 


DEVADDR=SYSLST 
IOAREA1=ERRMSG 
MODNAME=OUTMOD 
RECSIZE=121 
ERROPT=IGNORE 


ISMOD: The characteristics of the ISAM module (ISMOD) 
are specified through the use of the ISMOD macro. The 
name of this module within IJLFUPDT is UPDTMOD. Its 
characteristics are defined as follows: 


ERREXT=YES 
IOROUT=ADDRTR 
RECFORM=FIXUNB 
TYPEFLE=RANDOM 


DIMOD: The characteristics of the device independent 
module (DIMOD) are specified through the use of the 
DIMOD macro. The name of this module within IJ LFUPDT 
is OUTMOD. Its characteristics are defined as follows: 


TYPEFLE=OUTPUT 
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The message modules IDFMO1 and IJLFMO1 are organized 
alike. Figure 3-32 illustrates this organization. The mes- 
sage modules contain all of the text messages that are writ- 
ten out to a printer or print queue or to the operator con- 
sole during the execution of the Control and Storage steps. 
(DOS messages are written out to the printer exclusively.) 
The messages are grouped this way to ease their translation 
and alteration. IDFMO1 must reside in either the system 
link library or in a user-defined job/step library; IJLFMO1 
must reside in a core-image library. 

When the need arises to write out a message during the 
execution of the Control or Storage step, the message mod- 
ule is loaded into main storage. The index is examined to 
determine the address of the appropriate detail message. 
The message is composed by the diagnostic writer routine 
of the step requiring the message. Certain fields within the 
message are added by the diagnostic writer, such as the 
number of CSECTs processed, the temporary name used to 
store an FD program or its real member (FD program) 
name, the deck ID, the card sequence number, etc. The 
message is then written out to the appropriate file. 


Indexes to Control Messages 
Indexes to Storage Messages 


Control and Storage 
Message Text 


Figure 3-32. Modules IDFMO1 and IJLFMO1 Organization 
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IS THIS AN 
END RECORD 


CARDERR 


RESET THE 
ESD RECORDS 
PUNCHED /NOT 
PUNCHED 
INDICATOR 


RESET THE RESET THE ITEM 
GETCHECK COUNTER 
COMPARANDS TO ADDRESS 


THEIR INITIAL 
VALUES 


COUNTER, AND 
ESD NAME FIELD 


GETCHECK 


READ IN A 
RECORD FROM 
SYSIPT 


ENDPCH 


WAS EOF 
ENCOUNTERED 
IN THE READ 
OPERATION 


EOFRTN 


SET THE I TMSAVE 
INDICATOR TO 3 


NO 


CARDERR 
L) 


3 


ESTABLISH THE 
BINARY OFFSET 
FOR THE 
REQUIRED 
MESSAGE 


PLACE THE 
BINARY OFFSET 
IN REGISTER 3 


LOAD THE 
MESSAGE 
MODULE 

{| JLFMOl) 


USE THE BINARY 
OFFSET TO FIND 
THE PROPER 
MESSAGE IN 
] JLFMO | 


MOVE THE 
MESSAGE INTO 
THE OUTPUT AREA 


DOES 
THE MESSAGE 
REQUIRE 
DYNAMIC 
DATA 


WRITE OUT THE 
MESSAGE TO 
SYSLST 


CLOSE THE 
SYSLST FILE 


EXIT TO THE 
OPERATING 
SYSTEM 
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MOVE THE 
DYNAMIC 
INFORMAT ION 
INTO THE OUTPUT 


NOTE: THE ENTRY POINTS TO MSGFAN 


ARE AS FOLLOWS: 


1) OPENERR I 7) ESDERRS 
2} OPENERR2 8) CARDERR 
3) ESDERRI 91 DECKERR 
4) ESDERR2 10) SYNADI 
5) ESDERR3 11) SYNAD2 


ESDERR4 CTEND 
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GETCHECK 


1S THE DECK 
ID CORRECT 


DA2 CI 
DA2 BI,HI 


DECKERR 


1S THE 
READ IN A SEQUENCE 
RECORD FROM NUMBER 
SYSIPT CORRECT 


SAVE THE 
YES SEQUENCE NUMBER 
FOR POSSIBLE 
USE IN A 
MESSAGE 


NAMUPD 


SHIFT THE DATA 
LEFT ONE INCREMENT THE 
POS! TION SEQUENCE NUMBER 


COMPARAND BY | 


DOES 
RECORD TYPE 
= PREVIOUS 
RECORD 
TYPE 


RETURN TO 
CALLER 


CARDERR 


WAS THE 

PREVIOUS 

RECORD TYPE 
ESD 


NO YES 


IS THIS 
RECORD TYPE 
TXT 


NO NO 


WAS THE 
TURN _OFF THE PREVIOUS NO 
FIRST RECORD" RECORD _ TYPE 
SWITCH TXT 


YES 


SAVE THE DECK 
IDENTIFICATION 


IS THIS NO 
RECORO TYPE 
END 


YES 


CARDERR 


CHANGE THE TYPE 
COMPARAND TO 
END 


SEQUENCE 
NUMBER = 
oool 


RETURN_TO 
CALLER 


CARDERR 


YES 


PUTCARD 


C4,64,H4 
Al 
,D3 


SELECT CARD 
HOPPER 2 


PUNCH A CARO 


RETURN TO 
CALLER 


CHANGE THE TYPE 


COMPARAND TO 
TXT 


RETURN TO 


CALLER 
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A DA4 
Bl 
> 
EOF RIN 
B 
> 


GENERATE A TXT 


Cc 
TXT FIELD 
S 
GENERATE AND 
INSERT AN 
D END - OF -DECK 
INDICATOR 
(X"FFFE*') 
> 


NAMUPD 


E INCREMENT THE 
SEQUENCE NUMBER 


COMPARAND BY | 


> 
LA A 
PUTCARD 
F PUT OUT THE TXT 
RECORD TO 
SYSPCH 
> 
G 
> 
H 
> 
J 
> 


3 \ 


GENERATE A NEW 
END RECORD 


NAMUPD 


INCREMENT THE 
SEQUENCE NUMBER 
COMPARAND BY |! 


PUTCARD 


PUT OUT THE END 
RECORD TO 
SYSPCH 


HAS THE 
END-OF -F ILE 
SWITCH BEEN 

SET 


CLOSE THE 
SYSIPT_AND 
SYSPCH FILES 


CTEND 


NAMUPD 


INCREMENT THE 


SEQUENCE NUMBER 
COMPARAND BY 1 


RETURN TO 
CALLER 
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OPEN THE 
SYSIPT AND 
SYSLST FILES 


SAVE THE 
LOCATION OF THE 
FIRST NAME 
FIELD IN RPLTAB 


GE TCARD 


READ _ IN A CARD 
FROM SYSIPT 


1S THE 
OPERAND 
"DEVICE=" 


1S THE 
OPTYPE 
"D2314" 


NO 


ERREXT 


SET DEVTYPE SET DEVTYPE IN 
RPLTAB TO RPLTAB TO e 


CDCTRe 


IS THE YES 1S THE NO 1S THE 1S THE NO 
OPERAND OPT YPE OPTYPE “LOAD" OPTYPE 
"OPT ILON=" "UPDATE" "LOADFST" 
NO YES 


ERREXT 


SET RUNTYPE 
RPLTAB TO 


SET RUNTYPE IN 
RPLTAB TO 2 


SET RUNTYPE IN 
RPLTAB TO 3 


CDCTR3 


IS THE INCREMENT THE 
OPERAND PARTIAL REPLACE 
“REPLACE=" AR 


CARD COUNTER BY 
ONE 


SET THE 

"REPLACE ALL" 

INDICATOR IN 
RPLTAB 


WAS THE 
REPLACE 
CARD MAXIMUM 
EXCEEDED 


SET THE ERROR 
FLAG 


PUT THE NAME IN 

POINT TC THE THE NEXT 
NEXT NAME FIELD AVAILABLE FIELO 
IN RPLTAB IN RPLTAB 


WRITE OUT THE 
PROPER ERROR 
MESSAGE TO 
SYSLST 


INCREMENT THE 
PARTIAL REPLACE POINT TO THE CLOSE THE 
CARD COUNTER BY NEXT NAME FIELD SYSLST FILE 
ONE iN RPLTAB 


FLSHCARD 
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GETCARD 


DB! DI 


NOTE: IF 


NO ERRORS ARE ENCOUNTERED DURING THE 


READ IN A PROCESSING OF THE CONTROL CARDS, THE ENTRY TO 
B CARD FROM ) 
SYSIPT TO EOFRTN 1S ACCOMPLISHED BY THE DOS SUPERVISOR, 
fie Saree ea ee AS SPECIFIED IN THE SYSIPT DTFDI MACRO 
® | EOF ADDR=EDFRTN < 
DO CARD | 
COLUMNS. 1 SET THE ERROR | 
c AND 2 CONTAIN FLAG | e 
4 /" 
| 
» | « 
| EOFRTN 
WRITE OUT THE 
1S CARD PROPER ERROR | 1S THE YES CLOSE THE 
D COLUMN 3 MESSAGE TO ERROR FLAG SYSIPT FILE D 
BLANK SYSLST SET 
NO 
» « 
SAVE RPLTAB IN EX!T TO THE 
1S A VALID A OPERATING 
E OPERAND COMMUNICATIONS SYSTEM E 
PRESENT AREA 
» « 
RETURN TO READ CONTROL 
CALLER CARDS FROM 
F SYSIPT UNTIL F 
EOF 1S 
ENCOUNTERED 
® « 
DOES FETCH 
G RUNTYPE [ JLFUPDT G 
® « 
FETCH 
H | JLFLOAD H 
> « 
FETCH 
J | ULFUPDT S| 
® « 
K K 
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l OAD RCDCHK 


ENTER 1S THE NAME 
A SUBF IELD LOADRTN 
VALID 
DCI 
» 
NAMERR 
IS THE 
OPEN THE COUNT NO 1S THERE AN LOAD A 
B |} JFDLIB AND SUBF IELD ERROR IN THE SECTOR 
SYSLST FILES VALID SECTOR 
» 
A A ERRERR 
LOADRTN | SMPUT IS THE 
SECTOR YES INCREMENT 
Cc LOAD THE FIRST WRITE THE INCOMPLETE |] JLNAME TO THE 
SECTOR RECORD OUT TO NEXT SECTOR 
[JFDLIB 
» 
INCERR 
SAVE THE SECTOR RETURN TO 
NAME AND COUNT IS THIS THE CALLER 
D SUBFIELDS OF END-OF -FORM 
THE FIRST KUPB 
CNTERR 
» 
INCREMENT THE 
COUNT SUBF IELD 
E COMPARAND BY 
ONE 
» 
ARE 
THERE MORE INCREMENT THE 
F KUPBS IN THIS RECORD COUNTER 
SECTOR BY ONE 
» 
RESET THE POINT TO THE 
G RECORD COUNTER NEXT RECORD IN 
THE INPUT AREA 
> 
f) A 
LOADRTN 
H LOAD THE NEXT 
SECTOR 
» 
J 
D> 
K 
I a 2 a 3 a 4 a 5 
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‘ | SMPUT 
A 
THE ENTRY POINTS TO MSGFAN 
ARE AS FOLLOWS: 
ig Rs SS SE Sy 4a 
1) NAMERR 6) CYLERR 
2) ERRERR T) DISERR 
WERE ESTABLISH THE 
THE INDEX ISSUE THE BINARY OFFSET 3) INCERR 8&8) SEQERR 
B AREAS SETFL MACRO FOR THE B 
INITIAL - REQUIRED 4) CNTERR 9} UNRCERR 
| ZED MESSAGE 
PRMERR CALLUPD 
Be 4 
WRITE OUT A 
RECORD TO THE IS THE PLACE THE 
Cc USER'S LIBRARY CYLINDER AREA BINARY OFFSET Cc 
FULL IN REGISTER 3 
B 4 
CYLERR 
WAS THE USE TRE BINARY 
DATA RETURN TO OFFSET TO FIND 
D WRITTEN OUT CALLER THE. PROPER D 
PROPERLY MESSAGE IN 
| JLFMO t 
> 4 
LOAD THE 
WAS THERE A ATTEMPT TO MES SAGE 
E DASD ERROR WRITE OUT THE MODULE E 
RECORD AGAIN (TJLFMO1) 
D> 4 
WAS THE 
WAS THERE A ATTEMPT MOVE THE 
F WRONG LENGTH SUCCESSFUL MESSAGE INTO F 
RECORD THE OUTPUT AREA 
D> 4 
UNRCERR 
RETURN TO 
CALLER WRITE THE WRITE OUT AN 
G MESSAGE QUT TO ———, EOF TO IJFDOLIB G 
SYSLST 
® 4 
PRMERR 
HAS THE 
YES WAS THERE A DATA AREA 
H DUPLICATE OVERFLOWED H 
RECORD 
eS 4 
PRMERR 
CLOSE THE 
YES WAS THERE A | JFOLIB AND 
J SEQUENCE SYSLST J 
ERROR FILES 
BS 4 
K (=) K 


SEQERR 
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ESTABLISH 


ENTER IS THIS THE THE PROPER 
LAST FD BINARY OFFSET 
PROGRAM IN REGISTER 3 


WAS A 
TEMPORARY 
UPDATE IN 
PROCESS 


1S THIS THE 
END-OF -FORM 


CHANGE THE 
[JFDLIB DTFIS 
MACRO TO 
INDICATE A 2314 
DEVICE 


INCREMENT THE 
SAVED COUNT 
FIELD BY ONE 


WAS 
OPEN THE YES 1S A NEW THIS THE 
|JFDL!B AND LOAD NEEDED LAST KUPB_IN 
SYSLST FILES THE PHASE 


Li) Ay 
LOADRTN 


LOAD A PHASE 


a8. A, 
LOADRTN 


LOAD A PHASE 


R4 = R4 + 486 
POINT TO THE 
NEXT KUPB_IN 
THE CURRENT 
PHASE 


R4 = R4 + 486 
POINT TO THE 
NEXT KUPB_IN 
THE CURRENT 
PHASE 


SAVE THE NAME WAS A RESET THE 
AND COUNT TEMPORARY "TEMPORARY 
SUBF IELDS NAME USED NAME" FLAG 


ESTABLISH 
THE PROPER 
BINARY OFFSET 
IN REGISTER 3 


1S THE NAME 
FIELD CORRECT 


ESTABLISH 
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COUNT FIELD AN ERROR IN BINARY OFFSET PRINT OUT THE 
CORRECT ASSEMBLY IN REGISTER 3 PROPER ERROR 


MESSAGE 


IS THE 
FD PROGRAM 
INCOMPLETE 


ESTABLISH 
THE PROPER 
BINARY OFFSET 
IN REGISTER 3 


PUT OUT A 
RECORD TO THE 
}JFDLIB FILE 


ESTABLISH 
THE PROPER 
BINARY OFFSET 
IN REGISTER 3 
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PRINT OUT THE 
PROPER INFOR- 
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ESTABL! SH 
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ESTABLISH 
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BINARY OFFSET 
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PROPER INFOR- 
MATION MESSAGE 
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DDt JI 
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OUTPUT 
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DUPLICATE FOUND 
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FULL 
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TEMPORARY 
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THE PROPER 
J BINARY OFFSET 
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BINARY OFFSET 
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BINARY OFFSET 
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PRINT OUT THE 
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CLOSE THE 
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LOADF ST 
OPERATION 


WAS REPLACE 
ALL SPECIFIED 


SEARCH THE 
REPLACEMENT 
TABLE FOR THE 
FD PROGRAM NAME 


WAS THE 
NAME FOUND 
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TEMPORARY 
NAMES 
AVAILABLE 


1S A 
TEMPORARY 
UPDATE IN 
PROCESS 
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NO 
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TEMPORARY 
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AVAILABLE 


ESTABLISH 
THE PROPER 
BINARY OFFSET 
IN REGISTER 3 


NO 
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UPDTNM 


UPDATE THE 
TEMPORARY NAME 
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SAVE THE 
ORIGINAL FO 
PROGRAM NAME 
FOR _A_LATER 

MESSAGE 


CHANGE THE KEY 
FIELD TO 
INDICATE A 


TEMPORARY NAME 
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READ IN_ THE 
RECORD TO BE 
REPLACED FROM 
| JFDLIB 


WAIT FOR THE 
PUT 


INPU 
OPERATION TO 
END 


WAS THE 
RECORD READ NO RETRY THE 
SUCCESSFULLY INPUT OPERATION 


YES 


MOVE THE RECORD 
TO _BE_STORED 


INTO THE WORK 
AREA 


WRITE OUT THE 
RECORD TO THE 
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WAIT FOR_THE 
OUTPUT 
OPERATION TO 
END 


WAS THE 
RECORD 
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RECORD READ 
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INCREMENT THE 
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NUMBER FIELD BY 
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RETURN TO 
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Chart DD4 DOS FD UTILITY STORAGE STEP: ISLFUPDT CHART 4 OF 4 


' e 2 e 3 e 4 e 5 


A (2+) A 
® 4 
FLUSH 
IS THIS THE MSGF AN MOVE THE 
B END-OF -DECK MESSAGE INTO B 
THE OUTPUT AREA 
DD! H4,A5,E5,G5 
DD2e K3,05,F5 
» 4 
EOJRTN 
1S THIS BRANCH ON 
THE FIRST NO 1S THIS A REGISTER 3 TO YES 
Cc PASS THROUGH NEW FORM THE PROPER Cc 
FLUSH MSGFAN INTERNAL 
ENTRY 
> 4 
REMOVE THE 
SET THE MORE KUPBS BRANCH AND LINK EJECT CHARACTER 
D “FIRST PASS" AVAILABLE IN FROM THAT ENTRY FROM THE OUTPUT io) 
SWITCH THIS TO DIAGWTR AREA 
B 4 
CHKF ORM 
DOES DOES IT 
IS THIS THE HAS [JULFMO! THE MESSAGE NEED THE FD NO 
E END-OF -FORM BEEN LOADEO NEED THE FD PROGRAM AND E 
PROGRAM TEMP 
NAME NAMES 
® 4 
ARE ANY MOVE THE FD MOVE THE FO 
MORE KUPBS LOAD PROGRAM NAME PROGRAM ANO 
F AVAILABLE IN ]JLFMO | INTO THE OUTPUT TEMPORARY NAMES F 
THIS AREA INTO THE OUTPUT 
PHASE AREA 
B 4 
R4 = R4 + 486 USE THE BINARY 
POINT TO THE OFFSET PRINT QUT THE 
G NEXT KUPB_ IN REGISTER MESSAGE G 
THE CURRENT LOCATE 
PHASE 
> 4 
RETURN TO 
RESET THE CALLER 
H "FIRST PASS” H 
SWITCH 
D> 4 
J J 
D> 4 
K K 
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Entry 
Point 
Name 


CALLOAD 
CALLOAD 
CNTLEND 
CNTLINIT 
CNTLINIT 
CNTLSTMT 


CNTLSTMT 


CTLSYNER 


DIAGWTR 
DIAGWTR 
DIAGWTR 
DIAGWTR 
DIAGWTR 
ENTAB 
EOFRTN 
EOJRTN 
EOJRTN 
ERREXT 


ERREXT1 


ESDPROC 
ESDPROC 


FLSHCARD 


FLUSH 
GET 


GETCARD 


GETCHECK 


GETCHECK 


IDFMO1 


IJJFCBIC 
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Directory 


Name of Routine 
or Table 


Load Initial 
Update Initial 
Control End 
Control Initial 
Control Initial 
Create Control 
Statements 
Create Control 
Statements 
Control 
Synchronous |/O 
Error 

Diagnostic Writer 
Diagnostic Writer 
Diagnostic Writer 
Diagnostic Writer 
Diagnostic Writer 
Entry Table 
End-of-File 
End-of-Job 
End-of-Job 
Common Error 
Exit 

Special Error 
Exit 

ESD Processor 
ESD Processor 
Flush Cards 
Flush FD Program 
Get and Process 
Control Cards 
Get and Validate 
a Control Card 
Get and Check an 
Input Record 
Get and Check an 
Input Record 

OS FD Utility 
Message Module 
\JLFCT DIMOD 


Module 
Name 


IJLFLOAD 
IJLFUPDT 
IDFCT 
IDFCT 
IJLFCT 


IDFCT 


IJLFCT 


IDFCT 
IDFCT 
IDFST 
IJLFCT 
IJLFLOAD 
IJLFUPDT 
IDFST 
IJLFST 
IJLFLOAD 
IJLFUPDT 


IJLFST 
IJLFST 
IDFCT 
IJLFCT 
IJLFST 
IJLFUPDT 
IJLFST 
IJLFST 
IDFCT 
IJLFCT 


IDFMO1 
IJLFCT 


PLM 
References 
Chart 
Section ID 
3 DC1 
3 DD1 
3 OA3 
3 OA1 
3 DA1 
3 OA3 
3 DA1 
3 OA5 
3 OA4 
3 OB4 
3 DA2 
3 DC2 
3 DD4 
2 — 
3 DB2 
3 DC2 
3 DD2 
3 DB2 
3 DB1 
3 OA1 
3 DA1 
3 DB2 
3 DD4 
3 DB1 
3 DB2 
3 OA4 
3 DA3 
3 Sees 
3 —— 


Entry 
Point 
Name 


IJLFMO1 


INMOD 
ISMPUT 
ISMPUT 
LOADMOD 
LOADRTN 
LOADRTN 
MSGFAN 
MSGFAN 
MSGFAN 
MSGFAN 
MSGFAN 
NEWMEM 
OBJCARD 


OPEN 
OUTMOD 
OUTMOD 


PARMPROC 


PUTCARD 
PUTCARD 
RCDCHK 
RCDCHK 
REPLTAB 
RPLTAB 
SEGPROC 
SEGTAB 
STGEND 
STGINIT 
SYNAD1 


SYNAD2 


TXTPROC 
TXTPROC 
UPDTMOD 
UPDTNM 


Name of Routine 
or Table 


DOS FD Utility 
Message Module 
IJLFST DIMOD 
ISAM Put 
ISAM Put 


Module 
Name 


IJLFMO1 
IJLFST 
IJLFLOAD 
IJLFUPDT 


IJLFLOAD ISMOD IJLFLOAD 
Load Overlay Phases IJLF LOAD 
Load Overlay Phases IJLFUPDT 


Message Fan-in 
Message Fan-in 
Message Fan-in 
Message Fan-in 
Message Fan-in 
New Member 
Card Image 
Storage Area 
Open Files 


IJLFLOAD DIMOD 
IJLFUPDT DIMOD 


PARM Processor 
Put Out a Card 
Put Out a Card 
Validate Records 
Validate Records 


Replacement Table 
Replacement Table 
Segment Processor 


Segment Table 
Storage End 
Storage Initial 
Control 
Synchronous I/O 
Error 

Control 
Synchronous I/O 
Error 

TXT Processor 
TXT Processor 


IJLFUPDT ISMOD 


Update Name 


IDFCT 
IDFST 
IJLFCT 
IJLFLOAD 
IJLFUPDT 
IDFST 


IDFCT 
IJLFST 
IJLFLOAD 
IJLFUPDT 
IDFST 
IDFCT 
IJLFCT 
IJLFLOAD 
IJLFUPDT 
IDFST 
IJLFST 
IDFST 
IDFST 
IDFST 
IDFST 


IDFST 


IDFST 
IDFCT 
IJLFCT 
IJLFUPDT 
IJLFUPDT 
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Chart 
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Section 5: Data Area Layouts 


The information that would ordinarily be contained in this 
section has been placed in the text of Sections 2 and 3 to aid 
the discussion there. Refer to Section 2 for the layout of 
SEGTAB and ENTAB and to Section 3 for the layout of 
REPLTAB and RPLTAB. 
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Section 6: Diagnostic Aids 


No information is provided for this section because of the 
simplicity of the FD utility programs. 
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Appendixes and Glossary 4-1 


Contents 


Appendix A: Format of the Form Description Macro 
Instructions 


Appendix B: The Form Description Diagnostic Macros 
FDDSPLY Macro 
FDTRACE Macro 


Appendix C: Diagnostic Messages 

MNOTE Messages a. nae 
Informational MNOTE Messages 
Warning MNOTE Messages. . 
Termination MNOTE Messages 

FD Program Error Message 

Data Source Error Message 


Appendix D: Sample FD Program 


Glossary . 


4.3 


4-5 
4-5 
4.5 


4-6 
4-6 
4-6 
4-8 
4-10 
4-14 
4-14 


4-15 
4-27 


Appendix A. Format of the Form Description Macro Instructions 


; 


[symbol] FDPAGE 
[symbol] FDLINE 


[symbol] FDFIELD 


FI D='ddd’ 


[,PACKING= \ NO ] 
YES 


DELIMIT 
[,DEVICES=(3735,K[D] ) ] 


[BUFFERS=([RPB] [,(LPB[, 


[,MRGSTOP= {$ \] 


mene ya eh L Pen 
d d 


‘string’ *string’ 
LHTAB=(d[,d] ...)] 


[pagenum] [,HEIGHT= (es) ] 
d 


[,VMRG=([ {1 IL, y height y 1) 1 
dt db 


LSAVELOC= (NO ) ] 
{ves | 
d 


[ La ] | WIDTH= { 88} ] 
SKIP(d) 
[.HMRG=([ { mrgstop+t \ l{, { width 1) ] 


[ CYCLE=([d] [, igi [,target] ) ] 
[. SAVELOC=( NO ) ] 

ves | 

d 


i ( hogs hmrgd| comping) |] 
prevar’ ° fine \ 
dr 
ere 
L.CTR=( (d,op[,FIELD]) [,(d,op[,FIELD])] ...)] 
LIND=((d,logexp)[,(d,logexp) ] ...) ] 
[,CYCLE=([d ] [,limit] [,target] ) ] 
[SAVELOC= (NO) ] 
{vest 

d 
[SOURCE= (origin[,qualifier] ...) ] 
LKIND= (U_ ) ] 


A 
N 
AN 
K 
| SELFCHK= (NO 
ee .cenontyi)t 


ab 
d1 d2 


ia 
11 
— { 


.) ,LMAX,] edulis \ : ] 


d 

[,COMPARE=([FIELD,] comparopr,comparand 

[, gen ,LFIELD,] comparopr,comparand] ...) ] 

OR 

[SINK=([ (destination [,qualifier] ...) ] 

[,[ (destination [,qualifier] ...)]]...)] 
[ JUSTIF Y=([justcode] [,] justcode]] ...) ] 
[,FILL=((‘char’] [,[‘char’]] ...) a 


= ] Ticaay) 
pes (ye) LE {NO 


[, PICTURE=([‘picturespec’] 
[,[’picturespec’]] ...) ] 
[,BATCH=d] 
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[,CTR=( (d[,CLR] [,op,opnd] ...) 
[,(d[,CLR] [,op,opnd] ... ) }...)] 


LIND=((d, (ON ) )L(d, (ON) )]...)] 
OFF OFF 
INV INV 


[ TOTAL=( (d,‘fid’,CTR (d) ) 
[,(d,‘fid’,CTR(d))]...)] 

[ COMMAND=( (cmndgrp) [, (emndgrp) ] ...) ] 

[,.GOTO=target] 

[,CYCLE=([d] [,limit] [,target]) ] 

see Ne ] 


YES 


[symbol] FDCTRL [1F=(logterm[, Corie jlogterm] . 
d 


[symbol] | FDEND | (This macro has no operands.) 
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FDDSPLY MACRO 


The FDDSPLY macro provides the ability to display the 
global variables (arrays) used in the FD macro processing. 
FDDSPLY should be specified simply: 

FDDSPLY 
The macro, the first time it is coded, turns on the &PIB (47) 
global bit which activates the IDFDSP inner macro. To turn 
off the global bit, code another FDDSPLY macro after you 
have displayed all the information you want. If you do not 
code another FDDSPLY macro, the &PIB (47) bit is turned 
off automatically at the end of the assembly. 

IDFDSP inner macros are already scattered within the 
internal code waiting to be invoked by FDDSPLY. To add 
more IDFDSP inner macros, use either the IEBUPDTE util- 
ity program for OS or the MAINT library maintenance pro- 
gram for DOS. Refer to the JBM System/360 OS Utility 
publication, GC28-6586 for the way to specify the 
IEBUPDTE utility. To discover how to use the MAINT pro- 
gram, refer to the JBM System/360 DOS System Control 
and System Service Program, GC24-5036, publication. 

The format for the IDFDSP inner macro is as follows: 

IDFDSP {‘string’ 


‘string’ 
vname >, <vname >,... 
QUEUE QUEUE 


specifies a character string that is emitted 
during the display. This string may be used 
to indicate the position where the IDFDSP 
inner macro is inserted. 


where 


‘string’ 


is the name without the ampersand of a 
global variable to be displayed. If the vari- 
able has only one character (i.e. A, B, etc.), 
all of the one-character variables are displayed. 
If the variable requested has a companion vari- 
able (i.e., &PIA and &PIB), the companion 
variable is also displayed. 
specifies that all queue variables are to be 
displayed. 
There is no limit to the number of suboperands that can be 
coded on the IDFDSP inner macro for the H assembler. 
However, the D assembler can handle only 100 suboperands 
and the F assembler can handle only 200 suboperands. 

The IDFDSP inner macro generates MNOTE messages 
displaying the information requested for each macro. 


Examples: 


1. IDFDSP ‘AFTER GOTO’, QUEUE, PRTA 
This example specifies that the display is to begin where 
ever an IDFDSP inner macro is found, no matter what is 


wname 


QUEUE 
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coded in the ‘string’ operand. All of the queue variables 
are to be displayed, along with the &PRTA global 
variable. 

2. IDFDSP ‘AFTER PAGE CALCULATIONS’,DFA,PRTA,A 
This format requests a display of the DFA, &PRTA, 
and &A global variables and needs to be inserted into the 
inner macro code after the page calculations. All of the 
one-character variables are displayed because a display of 
the one-character &A variable was specified. 


FDTRACE MACRO 


The FDTRACE macro requests a trace of the entry to and 
exit from each outer and inner macro that is called during 
FD macro execution after an FDTRACE macro in the 
source deck. FDTRACE should be specified: 


FDTRACE 


The FDTRACE macro, the first time it is coded, turns on 
the &PIB (48) global bit, which activates the tracing func- 
tions. To turn off the bit, code another FDTRACE macro 
at the end of the area you want to trace. If you do not 
code another FDTRACE macro, the &PIB (48) bit is 
turned off automatically at the end of the assembly. 

FDTRACE generates an MNOTE message to display the 
trace information: 


IDF100 IN TRACE MODE es ale 

LEAVING 
Example: \f you wish to display some variables and trace 
the macro processing of an FDCTRL outer macro, code 
the following statements. 


FDDSPLY 
FDTRACE 
FDCTRL GOTO 
FDDSPLY 
FDTRACE 


The first FDDSPLY turns on the &PIB (47) global bit and 
activates the IDFDSP inner macros in the FDCTRL macro. 
The following FDTRACE macro turns on the &PIB (48) 

bit to begin the tracing activity. The FDCTRL outer macro 
processing is traced and all appropriate global variables spec- 
ified on IDFDSP inner macros are displayed. When the 
FDCTRL GOTO processing is finished, the second 
FDDSPLY and FDTRACE macros turn off the &PIB (47) 
and &PIB (48) bits, respectively, to stop the display and the 
trace. If the second pair of diagnostic macros are not spec- 
ified, the display and trace continue until the end of the 
assembly. 
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Appendix C: Diagnostic Messages 


MNOTE MESSAGES 


The descriptive and diagnostic MNOTE messages that can 

be generated by the Form Description macro instructions 
are described in this section. The general format of the mes- 
sage presentation is as follows: 


severity code (*for descriptive messages), ‘message text’ 


Refer to the publication JBM 3735 Programmer's Guide, 
GC30-3001, for a detailed explanation of each message. 

A severity code of “*” indicates an informational mes- 
sage. Other severity codes indicate more severe errors. 

The internal error message IDF999 appears when the 
program detects an unusual or invalid internal error. Other 


lines follow this error message to give a more detailed ex- 
planation of the error. 

Refer to Figure 4-1 for a list of the relationship of the 
&M global variable with each of the message operands. 


Informational MNOTE Messages 


The informational MNOTE messages have a severity code of 
asterisk and relate information about system parameters. 
These messages include also the FD program logic MNOTE 
messages that relate the starting and ending of paths and 
segments. 


Message Issued By Call No. 
* !DF100 IN TRACE MODE —— Each Macro 
LEAVING 

* IDF101 FORM NAME IS name MSG 001 
* IDF102 FORM ID IS ddd MSG 002 
*  1DF103 TABS SET AT COLUMNS t1, t2, t3, t4, t5 MSG 003 
*, 1DF104 PAGE pp INCLUDES LINE n1 MSG 004 
= THROUGH n2 WITHIN THE FORM 
*, IDF105 FDEND NOT NEEDED MSG 007 
*,  IDF106 CTR(d) USED AS ACCUMULATOR MSG 019 
* 1DF107 CTR(d) USED AS GENERATOR MSG 020 
*_ 1DF108 STARTING PATH p MSG 027 
*, IDF109 STARTING SEGMENT s MSG 028 
*, !1DF110 END OF SEGMENT s MSG 029 
*,1DF111 END OF PATH p MSG 030 
*, 1IDF112 INDICATORS USED IN PATH p MSG 031 
* IDF113 IND(d) MSG 032 
*,  1DF114 COUNTERS USED IN PATH p MSG 033 
*, IDF115 CTR(d) MSG 034 
*, 1DF116 BUFFERS USED IN PATH p MSG 035 
*,1DF117 STANDARD DEFAULTS NOT OVERRIDDEN BY FDFORM MSG 036 
*, 1DF118 THIS SEGMENT ENTERED FROM SEGMENT s MSG 039 
* 1DF119 THIS PATH ENTERED FROM MSG 040 
ey SEGMENT s OF PATH p 
*, 1IDF120 (FORM ) LEVEL ATTRIBUTES CHANGED FROM (STANDARD MSG1 

PAGE FORM 

LINE PAGE 

FIELD LINE 


Note: This message appears automatically as heading information 
for messages |DF122 through IDF128, inclusive. 
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Message 
* IDF121 NO ATTRIBUTES CHANGED AT (FORM \) LEVEL 
PAGE 
LINE 
“ FIELD 
* IDF122}WIDTH IS dd 
HEIGHT 
MRGSTOP 
* IDF123( LEFT MARGIN IS dd 
RIGHT 
TOP 
BOTTOM 
* IDF124 KIND IS UNDEFINED 
ALPHABETIC 
NUMERIC 
KATAKANA 
* 1DF125 SINK d IS / UNUSED 
TMT 
CTR (n) 
RPB,n 
PRT, 
LPB,n 
PCH,n 
INQ, n 
* IDFI2Z64FILL FOR SINK d IS{ LEFT 
JUSTIFY CENTER 
UNDERLINE RIGHT 
BLANK 
ZERO 
SPECIFIED 
NOT SPECIFIED 
* IDF127 SELF-CHECK OPTION IS NOT USED once 
MODULO 10 
MODULO 11 
* 1DF128 SOURCE IS ee artalaly REQUIRED ee 
NUMPAD JOETIONAL 
FID 
RSN 
EMITTED 
CTR (n) 
STG,Nn 
INQ,n 
RDR,n 
RPB,n 
LPB,n 
* IDF129 INDd TESTED 
SET 
INVERTED 
* IDF130 | STG 
INQ 
RDR/PCH 
RPB 
LPB 
IDR 
CCR 
* IDF132 AT END OF CYCLE PRINT ELEMENT WAS 
ist POSITIONED ON LINE dd OF FORM 


*, 1IDF133 NO TERMINATING ERRORS FOUND IN THIS FDP 
*, 1IDF134 SINK d OUTPUT COUNT IS digits 


*, 1IDF135 PICTURE WAS USED FOR FORMATTING 
Pa OUTPUT OF SINK d 


GENERATE 


NO AUTOEOF 


Issued By 
MSG1 


MSG1 


MSG1 


MSG1 


MSG1 


MSG1 


MSG1 


MSG1 


MSG1 


MSG1 


MSG3 


MSG3 
MSG3 
MSG3 


Call No. 
111 


120 


121 


122 


123 


124 


125 


126 


127 


130 


504 


512 
573 
577 
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Message 


*, IDF136 THIS SEGMENT BRANCHES TO SEGMENT ss OF PATH pp 
*, 1DF137 type FEATURE INDICATOR TESTED 

*, 1DF138 PACKING OPTION IS option 

*, IDF139 LINE NUMBER IS dd 

*,  1DF140 ind SPECIAL INDICATOR SET OR TESTED 

*, 1DF141 POSITION LIMITS FOR LPB ARE 1 AND n 

*, 1DF142 SOURCE/SINK OPTION FOR 5496 IS RPB 


*, IDF143 SELECTRIC Il PRINT REGION BEGINS AT 
ie COLUMN a, ENDS AT COLUMN b 


*,1DF144 TMT DATA FORMAT IS [ZERO OR] [a TO] b CHARACTERS 


[*, DELIMITED BY SEPARATOR] 
*, 1DF145 SOURCE CHARACTER COUNT ISn 
*, 1DF146 FORM DESCRIPTION PROGRAM SPECIFIED 


a SELECTRIC Il FORM HAVING nnn LINES 
[*, AND 3286 FORM HAVING nnn LINES] 


*, IDF147 SUMMARY OF FDP-GENERATED DATA 


UNPACKED FDP OUTPUT = nnn BLOCKS 
se 3735 DISK STORAGE = s1 .s2 SECTORS 


Warning MNOTE Messages 


The warning MNOTE messages have a severity code of zero 
and relate a warning that some unusual condition or param- 
eter has been found. Check each MNOTE message to be 
sure that the condition or parameter is actually what was 
desired. These messages, used along with the path and seg- 
ment messages, can assist in finding oversights and possible 
logic errors in the FD program. 


Message 
0,!1|DF400 FDFORM MUST START FORM 
0, |DF401 ELEMENT n OF HTAB OPERAND INVALID 


0, |IDF402 CTR(d) MAY NOT HAVE BEEN USED AS 
0, OUTPUT SINCE PRIOR INPUT 


0, IDF403 CTR(d) MAY NOT HAVE BEEN PROPERLY LOADED 
0, BEFORE CURRENT OUTPUT 

0, IDF404 IND d MAY NOT HAVE BEEN TESTED SINCE SET 

0, IDF405 IND d MAY NOT HAVE BEEN SET BEFORE TEST 

0, |IDF406 CTR(d) MAY NOT HAVE BEEN CLEARED 

0, BEFORE FIRST INPUT 

0, |IDF407 MESSAGE USED VERTICAL SPACING 

0, |IDF408 MESSAGE USED HORIZONTAL TABS 


0, 1DF409 CHAINING IN EFFECT, keyword OPERAND IGNORED 
keyword - From Figure 4-1. 


0, |IDF410 keyword IGNORED FOR DUMMY FIELD 
keyword - From Figure 4-1. 


0,1DF411 SUBOPERANDS AFTER SUBOPERAND n OF : 
0, keyword OPERAND IGNORED 
keyword - From Figure 4-1. 


0, |DF412 EXCESS CHARACTERS OF keyword 
0, SUBOPERAND n IGNORED 
keyword - From Figure 4-1. 


Issued By 


MSG . 
MSG1 
MSG1 
MSG 
MSG1 
MSG 
MSG 
MSG 


MSG1 
MSG3 


MSG3 


MSG3 


Issued By 
MSG 
MSG 
MSG 


MSG 


MSG 
MSG 
MSG 


MSG 
MSG 
MSG1 


MSG1 


MSG1 


MSG1 


Call No. 


017 
142 
129 
026 
143 
048 
049 
050 


144 


578 


579 


580 


Call No. 
008 
011 
021 


022 


023 
024 
025 


037 
038 
100 


101 


104 


105 


Message 


0, |DF413 POSSIBLE DUPLICATION OF EARLIER FORMS 


PAGES 
LINES 
FIELDS 
0, IN THIS FORM 
PAGE 
LINE 
FIELD 
0, IDF414 Ao d MAY NOT HAVE BEEN UNCONDITIONALLY 
lor 
0, SET IN FIRST OPERATION 


0, IDF415 UNPRINTABLE CHARACTER IN CHARACTER STRING 
0, |IDF416 CHARACTER NOT PRINTABLE ON ASCII 3735 


0, FOUND IN CHARACTER STRING 
0, 1DF417 CHARACTER NOT PRINTABLE ON EBCDIC 3735 
0, FOUND IN CHARACTER STRING 


0, |DF418 DEAD CODE, CYCLE IGNORED 
0, |IDF419 CYCLE WITHIN A CYCLE OR SUMMARY BLOCK IGNORED 
0, IDF 420 EXCESS CHARACTERS OF FIELD LNG(d) IGNORED 


0, 1DF421/ STG BUFFER MAY NOT HAVE BEEN USED AS 
INO 
RDR/PCH 
RPB 
LPB 
IDR 
CCR 
0, OUTPUT SINCE PRIOR INPUT 


0, IDF423 COUNT PREDETERMINED, COUNT OPERAND IGNORED 


0, |IDF424 SELFCHK OPERAND IGNORED FOR EMITTED "STRING" SOURCE 


0, |IDF425 ZERO FILL OPTION FORCES JUSTIFY RIGHT 


0, |DF426 COMPARE IGNORED FOR SOURCE FID OR EMITTED “STRING” 


0, |IDF427 KIND SET TO NUMERIC BY COMPARAND 

0, |IDF428 CTR IGNORED FOR EMITTED “STRING” SOURCE 
0,|DF429 KIND SET TO NUMERIC BY COUNTER OPERAND 

0, |IDF430 IND OPERAND IGNORED WITH SOURCE FID OR “STRING” 
0, |IDF431 COMMAND GROUP n, APPARENT RETROGRADE SKIPTO 
0, |IDF432 BRANCH WITHIN SUMMARY BLOCK IGNORED 

0, |IDF433 BRANCH INTO CYCLE OR SUMMARY BLOCK IGNORED 


0, IDF434 MAX COUNT CONSIDERED EXACT FOR 
0, NON-KEYBOARD SOURCES 


0, IDF435 MIN COUNT IGNORED FOR NON-KEYBOARD SOURCE 

0, IDF436 KIND OPERAND IGNORED WITH BATCH OR SELFCHK 

0, |IDF437 KIND OPERAND IGNORED FOR NUMERIC SOURCE 

0, IDF438 KIND OPERAND IGNORED WITH EMITTED SOURCE 

0, |IDF439 KIND IGNORED WITH CTR SINK 

0, |IDF440 FILL OPERAND IGNORED WITH EMITTED SOURCE 

0, |DF441 FILL OPERAND IGNORED FOR SINKd 

0, IDF442 NON-NUMERIC KIND OPTION IGNORED WITH ZERO FILL 
0, IDF443 JUSTIFY OPTION IGNORED FOR SINK d 

0, |DF444 UNDERLINE OPTION IGNORED FOR SINKd 


Issued By 
MSG1 


MSG1 


MSG3 
MSG3 


MSG3 


MSG3 
MSG3 
MSG3 
MSG1 


MSG3 
MSG3 
MSG3 
MSG3 
MSG3 
MSG3 
MSG3 
MSG3 
MSG 

MSG3 
MSG3 
MSG3 


MSG3 
MSG3 
MSG3 
MSG3 
MSG3 
MSG3 
MSG3 
MSG3 
MSG3 
MSG3 


Call No. 
113 


128 


501 
502 


503 


506 
507 
515 
131 


524 
528 
535 
537 
539 
540 
541 
543 
044 
547 
548 
549 


550 
551 
552 
553 
554 
555 
556 
557 
558 
559 
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Message 

0, |DF445 KIND SET TO NUMERIC BY IND OPERAND 

0, IDF446 PICTURE OPERAND IGNORED, SINK d NULL OR CTR 
0, IDF447 POSSIBLE OVERLAY OF SINKd 


0, IDF448 FIRST OPERATION ON ( STG )BUFFER MAY NOT HAVE 
INQ 
RDR/PCH 
\ RPB 
LPB 
IDR 
CCR | 
0, BEEN UNCONDITIONAL CLEAR OR INPUT 
0, IDF449/ STG ‘BUFFER MAY HAVE BEEN CLEARED 
INQ 
RDR/PCH 
RPB 
LPB 
IDR 
CCR 
0, OR INPUT WITHOUT PRIOR OUTPUT 
0, IDF450 (STG BUFFER MAY HAVE BEEN OUTPUT 
INQ 
RDR/PCH 
\ RPB 
LPB 
IDR 
CCR 
0, WITHOUT PRIOR INPUT 
0, |IDF451 FIRST OPERATION AFFECTING ind INDICATOR 
0, WAS NOT UNCONDITIONAL CLEAR OR SEND 
0, IDF452 ind INDICATOR MAY HAVE BEEN 
0, CLEARED WITHOUT PRIOR TEST 


0, |IDF453 SAVELOC IN SUMMARY BLOCK IGNORED 
0, |DF454 NAME OMITTED, SAVELOC IGNORED 
0, IDF455 SAVELOC COUNT NOT BETWEEN d1 AND d2 


O, ASSUME SAVELOC=YES 

0, IDF456 iad COMMAND MAY NOT HAVE BEEN ISSUED 
SEND 

0, WITHOUT PRIOR TEST OF pECE RBA INDICATOR 

TIMEOUT 

0, IDF 457 Neat INDICATOR MAY HAVE BEEN TESTED 
TIMEOUT 

0, WITHOUT PRIOR Baa COMMAND 

SEND 


0, IDF458 KIND SET TO NUMERIC BY PICTURE OPERAND 


0, |DF459 SAVELOC’D MACRO macro name 
0, nn UNUSED REFERENCES 


Termination MNOTE Messages 


The termination MNOTE messages have a severity code of 
eight and indicate that a severe error that suppresses the 
generation of the FD program has been found. The actual 
assembly process terminates. Although the assembly ends, 
the checking of operands continues as though no error had 
been found. An MNOTE message with a severity code of 
eight, if issued during the assembly of an FD program, flags 
the FD program as invalid. If this invalid FD program is 
used as input to the FD utility, the utility automatically 
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Issued By 


MSG3 
MSG3 
MSG3 
MSG1 


MSG1 


MSG1 


MSG1 


MSG1 


MSG 
MSG 
MSG 


MSG1 


MSG1 


MSG3 
MSG3 


Call No. 


563 
567 
574 
132 


133 


134 


140 


141 


005 
006 
009 


140 


141 


525 
581 


rejects the program. All errors associated with termination 
MNOTE messages must be corrected and the FD program 
assembled again before a valid FD program is generated. 
Message 

8, |DF700 MANDATORY FID OPERAND OMITTED 

8,|DF701 FORM NAME INVALID; subname SUBSTITUTED 

8, |DF702 INVALID BRANCH 

8, IDF703 PREVIOUS FORM NOT PROPERLY TERMINATED 

8, IDF704 PAGE WITHIN CYCLE IGNORED 

8, |DF705 FORM ENDED BEFORE CYCLE LIMIT ENCOUNTERED 


8, |DF706 EXPECTED CHAINING OF PRECEDING MACRO 
0, NOT FOUND, CHAINING TERMINATED 


8, |DF707 COMMAND GROUP n, ILLEGAL USE OF CLEAR 

8, |DF708 SKIPTO COMMAND ILLEGAL IN CYCLE OR SUMMARY 
8, |DF709 COMMAND GROUP n, SKIP OR SKIPTO NONDECIMAL 
8,|DF711 COMMAND GROUP n, PRINT ILLEGAL AFTER CLEAR 
8, |DF712 COMMAND GROUP n, ILLEGAL CLEAR OR READ 
8,1|DF713 COMMAND GROUP n, ILLEGAL DUE TO 


O, SPECIFICATION OF m DEVICE TYPES 
8,!1DF714 EXPECTED CHAINING OF keyword OPERAND 
O, NOT FOUND, CHAINING TERMINATED 


keyword - From Figure 4-1. 


8, |DF715 CHARACTER NEAR POSITION p OF keyword 
0, OPERAND IS ILLEGAL 
keyword - From Figure 4-1. 


8, |DF716 Weer ce MUST FOLLOW (FDFORM 


FDPAGE FDPAGE 
FDLINE FDLINE 
FDFIELD. FDFIELD 


8,|DF717 keyword OPERAND INVALID 
keyword - From Figure 4-1. 


8,1DF718 keyword OPERAND OMITTED 
keyword - From Figure 4-1. 


8, IDF719 keyword OPERAND 
0, NOT BETWEEN a AND b 
keyword - From Figure 4-1. 


8,|DF720 BATCH FOR keyword SUBOPERAND n INVALID 
keyword - From Figure 4-1. 


8. |IDF721 FID FOR keyword SUBOPERAND n INVALID 
keyword - From Figure 4-1. 

8, IDF722 CTR FOR keyword SUBOPERAND n INVALID 
keyword - From Figure 4-1. 


8, 1DF723 IND FOR keyword SUBOPERAND n INVALID 
keyword - From Figure 4-1. 


8, IDF724 EOF FOR keyword SUBOPERAND n INVALID 
keyword - From Figure 4-1. 


8, |IDF725 OPERATOR FOR keyword SUBOPERAND n INVALID 
keyword - From Figure 4-1. 


8, 1DF726 EMIT FOR keyword SUBOPERAND n INVALID 
keyword - From Figure 4-1. 


8,|DF727 BATCH FOR keyword SUBOPERAND n NOT 
O, BETWEENaANDb 
keyword - From Figure 4-1. 


Issued By 
MSG 
MSG 
MSG 
MSG 
MSG 
MSG 
MSG 


MSG 
MSG 
MSG 
MSG 
MSG 
MSG 


MSG1 


MSG1 


MSG1 


MSG2 


MSG2 


MSG2 


MSG2 


MSG2 


MSG2 


MSG2 


MSG2 


MSG2 


MSG2 


MSG2 


Call No. 
010 
012 
013 
014 
015 
016 
018 


041 
042 
043 
045 
046 
047 


102 


103 


112 


200 


202 


201 


212 


213 


214 


215 


216 


217 


218 


252 
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Message 


8, 1DF728 FID FOR keyword SUBOPERAND n NOT 
0, BETWEEN a AND b 
keyword - From Figure 4-1. 


8, IDF729 CTR FOR keyword SUBOPERAND n NOT 
0, BETWEEN a AND b 
keyword - From Figure 4-1. 


8, |DF730 IND FOR keyword SUBOPERAND n NOT 
0, BETWEENa AND b 
keyword - From Figure 4-1. 


8, IDF732 SKIP FOR keyword SUBOPERAND n NOT 
0, BETWEEN a ANDb 
keyword - From Figure 4-1. 


8, |DF733 INVALID CHARACTER IN MESSAGE SUBOPERAND n 


8, |IDF734 ATTEMPTED MOVEMENT TO A PREVIOUSLY 
0, DEFINED LINE INVALID 


8, |IDF735 CYCLE COUNT INVALID, COUNT OF 1 ASSUMED 


8, |IDF736 CYCLE COUNT NOT BETWEENa AND b 
0, COUNT OF 1 ASSUMED 


8, |DF737 TOO MANY UNRESOLVED BRANCHES 

8, |DF738 INVALID FORM DESCRIPTION PROGRAM 

8, |IDF739 DOCUMENT FIELD LNG(d) IS NONDECIMAL 
8,1|DF740 DEAD CODE, MACRO IGNORED 

8, |DF741 SOURCE KEYBOARD OPTIONS INVALID 

8, 1DF742 SOURCE START OR END POSITION INVALID 


8,|DF743 SOURCE START OR END POSITION NOT 
0, WITHIN THE RANGE a TO b 


8, |DF744 SOURCE LENGTH SPECIFICATION INVALID 
8,1DF745 SOURCE LENGTH NOT BETWEEN a AND b 

8, |DF746 MAX/EXACT COUNT NOT BETWEEN a AND b 
8,1|DF747 MINIMUM COUNT NOT BETWEENa AND b 

8, |DF748 START POSITION FOR SINK d INVALID 


8,1DF749 START POSITION FOR SINK d 
0, NOT BETWEEN a AND b 


8, 1DF750 LNG(d) FOR SINK d INVALID 

8,1DF751 LNG(d) FOR SINK d NOT BETWEEN a AND b 
8,1DF752 END POSITION FOR SINK d INVALID 
8,1DF753 END POSITION FOR SINK d 


O, NOT BETWEEN a AND b 
8, |DF754 NUMBER OF EMITTED “STRING” CHARACTERS 
0, NOT BETWEENa AND b 


8,1DF755 NUMBER OF CHARACTERS IN COMPARAND OF COMPARE 


0, SUBOPERAND n NOT BETWEEN a AND b 


8,1DF756 INVALID ARITHMETIC OPERATOR IN CTR 
0, SUBOPERAND n 


8,1DF757 INVALID COMPARAND LENGTH IN IND OPERAND 


8, |DF758 UNRESOLVED BRANCH TO name 
0, FROM PATH p SEGMENT s 


8, |DF759 LOGICAL OPERATOR NEAR POSITION p OF 
0, IND SUBOPERAND n INVALID 


8, |DF760 COMPARISON OPERATOR NEAR POSITION p OF 
OQ, IND SUBOPERAND n INVALID 
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Issued By 
MSG2 


MSG2 


MSG2 


MSG2 


MSG3 
MSG3 


MSG3 
MSG3 


MSG3 
MSG3 
MSG3 
MSG3 
MSG3 
MSG3 
MSG3 


MSG3 
MSG3 
MSG3 
MSG3 
MSG3 
MSG3 


MSG3 
MSG3 
MSG3 
MSG3 


MSG3 


MSG3 


MSG3 


MSG3 
MSG3 


MSG3 


MSG3 


Call No. 
253 


254 


255 


257 


500 
505 


508 
509 


510 
513 
514 
516 
519 
520 
521 


522 
523 
526 
527 
529 
530 


531 
532 
533 
534 


536 


538 


542 


544 
546 


560 


561 


Message 


8, |DF761 COMPARAND CHARACTER NEAR POSITION p OF 


0, 


8, |IDF762 IND COMPARAND LENGTH NOT BETWEEN 1 AND 127 
8, |IDF763 PICTURE ILLEGAL WITH EMITTED SOURCE 

8, IDF764 PICTURE ILLEGAL WITH NON-NUMERIC COMPARISONS 
8, |IDF765 LENGTH SPECIFICATION FOR SINK d IS INADEQUATE 
8, |DF766 PICTURE SUBOPERAND n IMPROPERLY FRAMED 


8,|DF767 CHARACTER c OF PICTURE SUBOPERAND n IS 
INVALID, MUST BE ONE OF THE FOLLOWING 


0, 
0, 


8, |IDF768 PICTURE SUBOPERAND n NOT PROPERLY TERMINATED 


IND SUBOPERAND n INVALID 


characters 


8, |DF769 SINK COUNT NOT BETWEENa AND b 


8,|DF770 PRINT ELEMENT POSITION CANNOT BE DETERMINED 
COUNT MUST BE CODED 


8,1DF771 PRINTING SINK EXCEEDS FIELD MARGINS 


8, IDF772 keyword OPERAND, SUBOPERAND n, FORMAT INVALID 
keyword - From Figure 4-1. 


0, 


Issued By 
MSG3 


MSG3 
MSG3 
MSG3 
MSG3 
MSG3 
MSG3 


MSG3 
MSG3 
MSG3 


MSG3 
MSG3 


8, |DF773 keyword OPERAND, SUBOPERAND n, NOT AN ALLOWED EXACT VALUE MSG3 


0, 


OR NOT BETWEENa AND b 
keyword - From Figure 4-1. 


8, 1|DF774 COMMAND GROUP n, INVALID FORMAT 


8, |DF775 COMMAND GROUP n, SKIP OR SKIPTO VALUE 
NOT BETWEEN a AND b 


8, |DF999 FDM SYSTEM ERROR 


Note: The four message inner macros MSG, MSG1, MSG2, and 
MSG3 also issue this message in-line. 


0, 


Re 
x 


OAN ODODWN —= 


Structural 
Operand Name 


SOURCE 

KIND 

SELFCHK 

SINK 

FILL 

JUSTIFY 

UL (underline) 
WIDTH 

HMRG 

SAVELOC 

NAME (macro name) 
Page or line number2 
Field left margin? 
CYCLE 

HEIGHT 

VMRG 

COUNT 


Control 1 
Operand Name 


IF 

IND 

CTR 
COMMAND 
TOTAL 
GOTO 


SAVELOC 
NAME 


CYCLE 


Figure 4-1. &M Operand Relationship for Keywords 


MSG1 
MSG1 
MSG 
Structural 

&M Operand Name 

17 COMPARE 

18 CTR 

19 IND 

20 PICTURE 

21 BATCH 

22 Field right margin? 

23 MESSAGE 

24 HTAB 

25 FID 

26 PACKING 

27 MRGSTOP 

28-59 Reserved 

1&PIB (3)=1 


2&PIA (1)=2 or 3 required 
3&PIA (1)=4 required 


Call No. 
562 


564 
565 
566 
568 
569 
570 


571 
572 
575 


576 
517 


518 


150 


151 


000 


Con trol 
Operand Name 
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FD PROGRAM ERROR MESSAGE 


When the terminal control program in the 3735 detects an 
invalid FCD byte, it issues an FD program error message. 
The message format is as follows: 


FDPERROR TT BB AAAA 


where 
TT is the type of byte in error: 
00 - immediate byte; 
Ql - data source byte; 
Q2 - data type byte; 
03 - function byte; 
04 - data sink byte; 
05 - end control byte; 


BB is the actual byte in error; 


AA AA are the two bytes that contain the address of 
the error byte relative to the beginning of the 
FD program sector. 


To correct this error, the following steps must be per- 
formed: 


1. Determine if the byte represented by BB is in error. If 
the byte is incorrect, check whether missing or extra 
bytes in the FD program are causing the terminal con- 
trol program to interpret BB incorrectly. (For example, 
a missing end control byte would cause the first byte of 
the next FCD to be interpreted as an end control byte 
and not as the first byte in the FCD.) 

2. Note the point in the form description where the error 
occurs (taking into account any possible branches to 
that point) by examining a PRINT GEN assembly listing 
of the FD program. Then modify the source level 
encoding to bypass the problem. Refer to the discussion 
of FD program maintenance in Part 2, Section 3 for fur- 
ther correction suggestions. 


DATA SOURCE ERROR MESSAGE 


When the terminal control program in the 3735 detects an 
error in a data field that has a source specified other than 
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the keyboard, it issues the data source error message. The 
message format is as follows: 


DATA SOURCE ERROR SS EE DT BB 
where 
SS specifies the data source type that is in error: 


50 - FD program ID (FID); 

51 - Record number; 

52 - Emitted data; 

53 - Counters; 

54 - Storage (STG) buffer; 

55 - Inquiry (INQ) buffer; 

56 - 5496 buffer; 

57 - 3286-3 buffer; 

SF - Operator Identification Card Reader (IDR or 
CCR) buffer; 

7F -CPU data; 


EE _ specifies the type of error: 
OO - Character type; 
05 - Value (range) check; 
10 - Self check; 
20 - Length error. 
When EE is 00 specifying a character byte, the DT 
and BB bytes are displayed: 


DT indicates the character type 
for the field: 
OO - data is undefined; 
10 - data is numeric only; 
20 - data is alphabetic only; 
30 - data is alphameric; 
40 - data is Katakana; 


BB _ indicates the character that caused the error. 


To correct this error, the user must check the coding of 
his outer FD macro statements to determine whether he has 
an invalid encoding. This error occurs as a result of speci- 
fying SOURCE#=storage buffer when the data in the buffer 
is not character data or as a result of the source counter not 
meeting the COMPARE test specified. 


Appendix D: Sample FD Program 


This appendix contains three sections: excerpts from three 
code sources to illustrate the correlation between (1) a 
PRINT GEN macro assembly listing, (2) a hexadecimal 
dump of the data created by the assembly, and (3) the 
internal 3735 code created. This information may aid in 
finding and solving problems in the assembly of FD pro- 
grams. 

The first section contains portions of a PRINT GEN 
macro assembly listing composed of excerpts from the 
sample FD macro program listed in Appendix C in the 
IBM 3735 Programmer’s Guide, GC30-3001. This sample 
program describes the sample form presented in Appendix 
A in the JBM 3735 Programmable Buffered Terminal 
Concept and Application publication, GA27-3043. The 
assembly listing contains alphabetic identification char- 
acters to relate specific parts of the listing to corresponding 
parts of the hexadecimal dump and the 3735 code that 
follow. Each alphabetic character and the portion of the 
FD program that it identifies is as follows: 


the form ID specified in the FID operand on the 
FDFORM macro. 

the data condensation specified in the PACKING 
operand on the FDFORM macro. 


—_ 
Ne 


the begin tab definition delimiter. 

the begin the FCD indicator. 

the specifications resulting from the coding of the 
FDFIELD macro named ADDRESS1. 

the specifications resulting from the coding of an 
FDFIELD macro for control-character input. 

the specifications resulting from the coding of the 
FDFIELD macro named DATEFLD. This 
FDFIELD macro illustrates a PICTURE specifi- 
cation. The macro also shows how the assembly 
uses ORG statements to go back and overlay parts 
of the object code with later form specifications. 
In this case, the data-type byte and the function 


Bae 


bn onl - 
— s 


the form length specified in the HEIGHT operand. 


byte are initially assembled as X*4175’ and X‘*4070’ 
and then replaced by X*4171’ and X°4170’ via two 
ORG statements. 

EH the specifications resulting from an FDCTRL macro 
with a GOTO branch that is dependent on the 
setting of an indicator in IND(2). If IND=OFF, 
this FDCTRL macro branches to the next FDCTRL 
macro. If IND=ON, the branch is to the FDFIELD 
macro named DELIVER. 

the specifications resulting from the FDLINE 
macro named BODY illustrating an example of a 
cycle. 

the repeat cycle indicator. 

the end cycle indicator specified in the FDLINE 


macro named GROSS. 
the end form indicator in the CSECT named 
IJLF1001. 


The hexadecimal dump in the second section of this 
appendix results from using one of the BTAM (OS or DOS) 
sample programs described in Appendix G or Appendix H 
in the JBM 3735 Programmer’s Guide, GC30-3001. Each 
of these programs reads data from the 3735, dumps it on 
the system printer if requested to do so, and then sends 
FD programs (if any) to the 3735. When through, the 
program sends the terminate communicate mode message 
to the 3735, issues a Write Disconnect macro, and con- 
cludes processing. This dump contains alphabetic identi- 
fication characters that match those in the PRINT GEN 
assembly listing to point to the fields generated by that 
macro assembly. 

The internal 3735 code in the third section of this 
appendix also contains alphabetic identification characters 
corresponding to those in the assembly listing and the 
hexadecimal dump. These characters further illustrate the 
individual specifications defined in the excerpts from the 
sample FD program in Appendix C in the JBM 3735 
Programmer’s Guide, GC30-3001. 


Appendix D 4-15 


J035 


LOC OBJECT CODE 


000000 


JOB035 


SALES INVOICE 


ADDR1 ADDR2 


000000 C6C4CEDEDID44O4O 


000008 
OOOOOA 
0001EC 
00000C 
00000c 
00000C 
00000C 


00000E/437 
0000 10/437 


000008 
000008 
OOOO0A 
000012 


4370 
2 
6 


0000 
4070 


4070 


FFFE 


000012 [4470 


000014 
000016 
000018 
OOOOTA 


00001C 
00001E 
000020 
000022 
000024 
000026 
000028 
O0002A 
0000 2c 
00002E 
000030 
0000 32 
000034 
000036 
000038 
OOOO3A 
00003C 
00003E 
0000 40 
000042 
000044 
000046 
000048 
OOOO4A 
00004C 
OO004E 
000050 
000052 
000054 
000056 
000058 
OOO0O5A 
00005c 
O0005E 
000060 
000062 
000064 
000066 
000068 
OO006A 
00006C 
00006E 
000070 
000072 
000074 
000076 
000078 
OOOO7A 
00007C 
OO0007E 
000080 
000082 
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4070 
4070 


4070 
4070 


4575 
4573 
4475 
4270 
4476 
4U7F 
4572 
447D 
4270 
4377 
4378 
4376 
4374 
4372 
4375 
W2TE 
4270 
4270 
4476 
4474 
4570 
4270 
4370 
4371 
4371 
4270 
447D 
4575 
4573 
4574 
4270 
4472 
4475 
4270 
4570 
4475 
4572 
4476 
I 
4572 
447D 
4475s 
4474 
4270 
4472 
4475 
4476 
uu7P 
4572 
4475 
4270 
4574 


STAT 


3 FDFORA 


h+* 
5 
6 


7+IJLF1000 START 


8+ 

9+ 
10+ 
11+ 
12+ 
13+ 
144 
15+ 
16+ 
17+ 
18 
19+ 
20+ 
21+FDFORA 
22+ 


SOURCE STATEMENT 


FDFORM FID='026', 
MRGSTOP=11, 
MESSAGE="USE FORM 786425. F 
ORE THIS FDP.', 
HTAB= (33,64), 

PACKING=DELIAIT 


CEKEKEREEE 


* 


FDP NO IS 026 x 
MECHANICAL LEFT MARGIN STOP Xx 


OPE 
HOR 
DEL 
FS 


FD MACROS CHANGE LEVEL 02/04/72, 1100 


DP 011 MUST BE PERFORMED BEFX 
RATOR INSTRUCTION x 
IZONTAL TAB STOP POSITIONS X 
ETE TRAILING BLANKS, ADD » ¢ 


CHARACTER TO EACH FIELD 
CeEEEEE EEE 


v 
*,IJLF101 FORM NAME IS FDFORM 


io) 


CL8*FDFORSM' 


H'O* 
X'4070° 


*-480 LENGTH 


x* 40708 


IJLF1000#12 ORG TO DESIRED LOCATION TO 


SECTOR HEADER - FORMNAHME 
SECTOR NUABER 


RESERVED SECTOR CHAIN 
*+480 SET VALID 


ATTRIBUTE 


GENERATED CONSTANT 


H*17264* GENERATED 


H' 17266° 


GENERATED 


H*17270* GENERATED 
*,IJLF102 FORM ID IS 026 
IJLF1000+8 ORG TO DESIRED LOCATION TO ASM NEXT BYTE 
GENERATED CONSTANT 
* ***TEST FOR DUPLICATE FORM NAMES IN THIS ASSEMBLY *** 
IJLF1000+18 ORG TO 


X'FFFE* 


H* 175208 
*, IJLF138 PACKING 


x*4070° 
x'40708 
x* 40708 
x*'4070° 


X*4575°8 
x'4573° 
x'4au75e 
xX*4270° 
X*44u76* 
X'4Qu7F* 
x*4572° 
X'4u7D° 
xX*4270°8 
X*4377! 
xX*4378¢8 
X*4376¢ 
X' 43748 
X*4372¢ 
X*4375°* 
X"*427E* 
x*°42708 
x*4270° 
X*4476° 
X*4Q74e 
x*45708# 
X*4270° 
xX*4370° 
X* 43718 
x°4371° 
X*4270° 
Xx'44u7D°* 
x*4575° 
x*4573°8 
X'4574¢ 
X'4270° 
Xx* 4472? 
xX'4a75s 
x" 42708 
x'4570°8 
Xx°4475° 
x* 4572! 
X*44u76°* 
X'44u7Fe 
X*4572° 
X*44u7D¢* 
X*4a75¢ 
X'4q74e 
x* 42708 
X*4472° 
X*44u75* 
X*Qu76t 
X*4u7F* 
x*4572° 
x*' 4475! 
x*4270° 
X'4574* 


GENERATED 


ARITHMETI 


ASH NEXT BYTE 


Cc 
ARITHMETIC A 
ARITHMETIC 


ASM NEXT 
ARITHMETI 


OFTION IS *DELIMIT* 


GENERATED CONSTANT 


GENERATED CONSTANT 
GENERATED rl 
GENERATED CONSTANT 
*,IJLF122 MRGSTOP 


TRANSLATED 
TRANSLATED 
TRANSLATED 
TRANSLATED 
TRANSLATED 
TRANSLATED 
TRANSLATED 
TRANSLATED 
TRANSLATED 
TRANSLATED 
TRANSLATED 
TRANSLATED 
TRANSLATED 
TRANSLATED 
TRANSLATED 
TRANSLATED 
TRANSLATED 
TRANSLATED 
TRANSLATED 
TRANSLATED 
TRANSLATED 
TRANSLATED 
TRANSLATED 
TRANSLATED 
TRANSLATED 
TRANSLATED 
TRANSLATED 
TRANSLATED 
TRANSLATED 
TRANSLATED 
TRANSLATED 
TRANSLATED 
TRANSLATED 
TRANSLATED 
TRANSLATED 
TRANSLATED 
TRANSLATED 
TRANSLATED 
TRANSLATED 
TRANSLATED 
TRANSLATED 
TRANSLATED 
TRANSLATED 
TRANSLATED 
TRANSLATED 
TRANSLATED 
TRANSLATED 
TRANSLATED 
TRANSLATED 
TRANSLATED 
TRANSLATED 
TRANSLATED 


Is 11 


CHARACTER 
CHARACTER 
CHARACTER 
CHARACTER 
CHARACTER 
CHARACTER 
CHARACTER 
CHARACTER 
CHARACTER 
CHARACTER 
CHARACTER 
CHARACTER 
CHARACTER 
CHARACTER 
CHARACTER 
CHARACTER 
CHARACTER 
CHARACTER 
CHARACTER 
CHARACTER 
CHARACTER 
CHARACTER 
CHARACTER 
CHARACTER 
CHARACTER 
CHARACTER 
CHARACTER 
CHARACTER 
CHARACTER 
CHARACTER 
CHARACTER 
CHARACTER 
CHARACTER 
CHARACTER 
CHARACTER 
CHARACTER 
CHARACTER 
CHARACTER 
CHARACTER 
CHARACTER 
CHARACTER 
CHARACTER 
CHARACTER 
CHARACTER 
CHARACTER 
CHARACTER 
CHARACTER 
CHARACTER 
CHARACTER 
CHARACTER 
CHARACTER 
CHARACTER 


BYTE AFTER HIGHEST 


J035 


LOC 


000084 
000086 
000088 
O0008A 
00008C 
00008E 
000090 
000092 


JOB035 SALES INVOICE 


OBJECT CODE ADDR1 ADDR2 


4478 
4479 
4573 
4270 
4476 
4474 
4570 
U27E 


000094 


000096 
000098 


4175 
417F 


00009a [4070] 


STAT 


SOURCE 


82+ 
8 3+ 


STATEMENT 

DC X'4478" TRANSLATED CHARACTER 

Dc X'4479* TRANSLATED CHARACTER 

Dc X'4573" TRANSLATED CHARACTER 

DC X'4270" TRANSLATED CHARACTER 

DC X'4476" TRANSLATED CHARACTER 

DC X'4474" TRANSLATED CHARACTER 

DC X'4570" TRANSLATED CHARACTER 

DC X'427E* TRANSLATED CHARACTER 

DC X'U77F* START TAB DEFINITION BYTES] D 

DC H'16757" GENERATED ARITHMETIC 

DC H' 16767" GENERATED ARITHMETIC 
*,IJLF103 TABS SET AT COLUMNS 33, 64 

DC X'4O70" GENERATED CONSTANT] 


* 


oe 
*,IJLF108 STARTING PATH 1 
* 


a 
*,IJLP109 STARTING SEGMENT 1 


ee 


0000 B6 
000086 
000088 
OOOOBA 
0000 BC 
0000BE 


0000C0 
0000C0 
0000C2 
0000C4 
0000C6 
0000C8 
OO00OCA 


4576 
4070 
4074 
4O74 
4174 


144 
145 
146 


148 NAME1 


149 +*FDFIELD 
150+NAME1 
151+ 

152+ 

153+ 

154+ 

155+ 

156 

157 

158 

159 

160 

161 

162 

163 


165 
166+*FDLINE 
167 
168 
169 
170 
171 


173 ADDRESS1 


174+*FDFIELD 
175+ADDRESS1 
176+ 

177+ 

178+ 

179+ 

180+ 

181+ 

182 

183 

184 

185 

186 

187 

188 

189 

191 
192+*FDLINE 
193 

194 

195 

196 

197 


*,IJLF122 WIDTH IS 85 
*, IJLF123 LEFT MARGIN IS COLUMN 12 
*, IJLF123 RIGHT MARGIN IS COLUMN 80 


NAME POSITION » ¢ 
GET FROM CARD IMAGE x 
PUT TO SELECTRIC II 


FDFIELD 12,31, 
SOURCE=(RDR, 1,20), 
SINK=PRT 

-360N-CQ-490 - CHANGE LEVEL 3-A 


EQU * *#* TEST FOR DUPLICATE NAMES *** 
DC H'17782' GENERATED ARITHMETIC 
DC H*16496" GENERATED ARITHMETIC 
DC H* 16500" GENERATED ARITHMETIC 
DC H*16500" GENERATED ARITHMETIC 
DC H' 16756" GENERATED ARITHMETIC 
*, 
*, IJLF125 SINK 11S PRT 
*,IJLP143 SELECTRIC II PRINT REGION BEGINS AT 
*, COLUMN 12, ENDS AT COLUMN 31 
*, 
*,IJLF128 SOURCE IS RDR, 1 
*,IJLF145 SOURCE CHARACTER COUNT IS 20 
*,IJLF124 KIND IS UNRESTRICTED 
FDLINE 13 SOLD-TO STREET ADDRESS LINE 


-360N-CQ-490 - CHANGE LEVEL 3-A 
+, 
*, IJLF139 LINE NUMBER IS 13 
*,IJLF122 WIDTH IS 85 
*,IJLF123 LEFT MARGIN IS COLUMN 12 
*,IJLF123 RIGHT MARGIN IS COLUMN 80 


STREET ADDRESS POSITION »¢ 
GET FROM CARD IMAGE x 
PUT TO SELECTRIC II 


FDFIELD 12,31, 
SOURCE= (RDR,21,40), 
SINK=PRT 


-360N-CQ-490 - CHANGE LEVEL 3-A 
EQU * ¢#¢ TEST FOR DUPLICATE NAMES *** 
DC H*17521* GENERATED ARITHMETIC 
DC H' 17782" GENERATED ARITHMETIC 
bc H*16496" GENERATED ARITHMETIC F 
DC H' 16760" GENERATED ARITHMETIC 
DC H*16500* GENERATED ARITHMETIC 
DC H' 16756" GENERATED ARITHMETIC 
*, 
*, IJLF125 SINK 11S PRT 
*, IJLF143 SELECTRIC II PRINT REGION BEGINS AT 
*, COLUMN 12, ENDS AT COLUMN 31 
*, 
*,ITJLF128 SOURCE IS RDR, 21 
*, IJLF145 SOURCE CHARACTER COUNT IS 20 
*,TJLF124 KIND IS UNRESTRICTED 
FDLINE 14 SOLD-TO CITY/STATE/ZIP LINE 
-360N-CQ~490 - CHANGE LEVEL 3-A 
*, 
*,IJLP139 LINE NUMBER IS 14 
*, IJLF122 WIDTH IS 85 
*, IJLF123 LEFT MARGIN IS COLUMN 12 
*,IJLP123 RIGHT MARGIN IS COLUMN 80 
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J035 JOB035 SALES INVOICE 


LOC OBJECT CODE ADDR1 ADDR2 STMT SOURCE STATEMENT 
237 FDFIELD , CONTROL-~CHARACTER INPUT xX 
SOURCE=(KBD,OPTIONAL) , GET FROM KEYBOARD X 
COUNT=1, SINGLE CHARACTER X 
COMPARE=(FIELD,£EQ,'K'), IF ENTRY MADE, MUST BE ‘K* x 
IND= (1, FIELD, EQ,'K*), FLAG ENTRY OF ‘'K'* » ¢ 
SINK=NULL NO OUTPUT 
238+*FDFIELD ~360N-CQ-490 - CHANGE LEVEL 3-A 
OO00E8 239+ DC X'*4070" GENERATED CONSTANT 
OOOOEFA 240+ DC H'16499* GENERATED ARITHMETIC 
0000 EC 241+ DC H*16497* GENERATED ARITHMETIC 
O000EE 242+ DC H' 17018" GENERATED ARITHMETIC 
0000F0 243+ DC H'16496* GENERATED ARITHMETIC 
0000F2 2444 DC H' 17008" GENERATED ARITHMETIC 
OOOOF4 245+ DC H*16497" GENERATED ARITHMETIC 
0000F6 246+ DC X*447B" TRANSLATED CHARACTER 
0000F8 247+ DC H*17008" GENERATED ARITHMETIC 
OOOOFA 248+ DC H*16497* GENERATED ARITHMETIC 
249+ TRANSLATE 
O0O000FC 250+ DC X'447B* TRANSLATED CHARACTER 
251+* END TRANSLATE 
252 *,IJLP129 IND 1 SET 
0000F0 253+ ORG IJLF1000+#240 ORG TO DESIRED LOCATION TO ASM NEXT BYTE 
0000 F0 254+ DC H*17008* GENERATED ARITHMETIC 
QOOO0OFE 255+ ORG IJLF1000+#254 ORG TO ASM NEXT BYTE AFTER HIGHEST 
OOOOFE 256+ DC H*' 16496" GENERATED ARITHMETIC 
257 *, 
258 *,IJLF128 SOURCE IS KEYBOARD, OPTIONAL, NO AUTOEOF 
259 *,IJLF145 SOURCE CHARACTER COUNT IS ZERO OR 1 
260 *, IJLF124 KIND IS UNRESTRICTED 
262 FDCTRL IF=IND(1),GOTO=KSHIPTO ON MEANS OPR. WILL KEY SHIP-TO 
263+*FDCTRL -360N+CQ-490 - CHANGE LEVEL 3-A 


521 HEADLINE FDLINE 23 HEADING LINE 


522+*FDLINE -360N-CQ-490 - CHANGE LEVEL 3-A 
00019A 523+HEADLINE EQU  * *** TEST POR DUPLICATE NAMES *** 
524 x, 
525 *,IJLF110 END OF SEGMENT 3 
526 *,IJLF109 STARTING SEGMENT 4 
527 *, 
528 *, 
529 * ,IJLP139 LINE NUMBER IS 23 
530 *, IJLF122 WIDTH IS 85 
531 *, IJLP123 LEFT MARGIN IS COLUMN 12 
532 *, IJLF123 RIGHT MARGIN IS COLUMN 80 
534 DATEFLD FDFIELD 12,19, DATE POSITION X 
SOURCE=(STG, 1,6) , GET FROM STORAGE (PRESET) X 
SINK=PRT, PUT TO SELECTRIC II X 
PICTURE='¥9/99/99', MM/DD/YY FORMAT Cc 
KIND=N 
535+*PDFIELD -360N-CQ-490 ~- CHANGE LEVEL 3-A 
00019A 536+DATEFLD EQU * *** TEST FOR DUPLICATE NAMES *#** 
00015E 537+ ORG IJLF10004#350 ORG TO DESIRED LOCATION TO ASM NEXT BYTE 
00015E 4770 538+ DC X'4770" GENERATED CONSTANT 
000160 4475 539+ DC H' 17525" GENERATED ARITHMETIC H 
O0019A 540+ ORG IJLF1000+#410 ORG TO ASM NEXT BYTE AFTER HIGHEST 
00019A 4475 541+ DC H' 17525" GENERATED ARITHMETIC 
542 *, 
543 *,IJLF118 THIS SEGMENT ENTERED FROM SEGMENT 3 
000162 S444 ORG IJLF1000+354 ORG TO DESIRED LOCATION TO ASM NEXT BYTE 
000162 4671 545+ Dc X'4671" GENERATED CONSTANT 
000164 4070 546+ DC H' 16496" GENERATED ARITHMETIC 
000166 417A 547+ Dc H'16762' GENERATED ARITHMETIC 
000168 4670 548+ DC X¥'4670" GENERATED CONSTANT 
00016A 4670 549+ DC X'4670" GENERATED CONSTANT 
00016C 4670 550+ DC X'4670" GENERATED CONSTANT 
00016E 4670 551+ DC X'4670" GENERATED CONSTANT 
000170 4670 552+ DC X' 4670" GENERATED CONSTANT 
000172 4670 553+ DC X'4670' GENERATED CONSTANT 
000174 4670 554+ pc X'4670' GENERATED CONSTANT 
000176 4670 555+ Dc X'4670" GENERATED CONSTANT 
556 *, 
557 *,IJLF118 THIS SEGMENT ENTERED FROM SEGMENT 2 
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3035 JOBO35 SALES INVOICE 
LOC OBJECT CODE ADDR1 ADDR2 STH#T 
00019Cc 558+ 
00019C 4574 559+ 
00019E 4070 560+ 
0001A0 4074 561+ 
562 
563 
0001A2 564+ 
0001A4 565+ 
0001A6 566+ 
0001A8 567+ 
0O001AA 568+ 
OO01AC 569+ 
OOO1AE 570+ 
0001B0 571+ 
000182 572+ 
0001B4 573+ 
0001B6 574+ 
0001B8 575+ 
OOO1BA 576+ 
0001BC 577+ 
0001BE 578+ 
0001AC 579+ 
0001AC 580+ 
581 
582 
583 
584 
0001A2 585+ 
0001A2 586+ 
0001A6 587+ 
0001A6 588+ 
589 
590 
591 
592 
593 
594 
596 INVNO 


SOURCE STATEMENT 


IJLF1000#412 ORG TO ASM NEXT BYTE AFTER HIGHEST 
H' 17780" GENERATED ARITHMETIC 
H'16496" GENERATED ARITHMETIC 

H* 16500" GENERATED ARITHMETIC 
0,IJLF448 FIRST OPERATION ON STG BUFFER MAY NOT HAVE 
0, BEEN UNCONDITIONAL CLEAR OR INPUT 
GENERATED ARITHMETIC 

GENERATED ARITHMETIC 

GENERATED ARITHMETIC 

GENERATED ARITHMETIC 

GENERATED ARITHMETIC 

GENERATED ARITHMETIC 

GENERATED CHARACTER 

GENERATED CHARACTER 
GENERATED CHARACTER 

GENERATED CHARACTER 
GENERATED CHARACTER 
GENERATED CHARACTER 
GENERATED CHARACTER 
GENERATED CHARACTER 
GENERATED CONSTANT 


H*'16506' 
H'16501! 
x'4579!8 
X*4379! 
X"427F! 
X'4379° 
X'4379°8 
X*'427F! 
x'4379° 
x'4379° 
X'477F# 


IJLF1000+428 ORG TO DESIRED LOCATION TO 


H* 16502' 
* 


ASM NEXT BYTE 


GENERATED ARITHMETIC 


e 
*, IJLF125 SINK 1 IS PRT 
*,IJLF143 SELECTRIC II PRINT REGION BEGINS AT 


*, 


H* 16753! 


H* 16752! 


COLUMN 12, 
GENERATED 


GENERATED 


ENDS AT COLUMN 19 
IJLF1000+#418 ORG TO DESIRED LOCATION TO 
ARITHMETIC 
IJLF10004#422 ORG TO DESIRED LOCATION TO 
ARITHMETIC 


ASM NEXT BYTE 


ASM NEXT BYTE 


*, IJLF135 PICTURE 1 WAS USED FOR FORMATTING 
OUTPUT OF SINK 1 


* 
* 


’ 


a 
*,IJLF128 SOURCE IS STG, 1 
*, IJLF145 SOURCE CHARACTER COUNT IS 6 
*,IJLF124 KIND IS NUMERIC 


FDFIELD 21,28, 


SOURCE= (STG,7,13), 
CTR=(1,ADD,FIELD), 


SINK=(PRT,TMNT) , 


PICTURE= ("99899999 , 99899999") 


INVOICE NUMBER POSITION x 
GET FROM STORAGE (PRESET) X 
PREVIOUSLY CLEARED 

PUT TO SEL. II AND TMT X 
PICTURES SHOULD AGREE 


ee ee 2, me ee eee ere 


B44 * 
846 
847+*FDCTRL 
OO0O02AC 848+ 
0002AE 849+ 
850 
000280 851+ 
0002B2 852+ 
0002B4 853+ 
0002B6 854+ 
0002B8 855+ 
QOO2BA 856+ 
0002BC 4670 857+ 
OO0O02BE 4670 858+ 
0002CO 4670 859+ 
0002c2 4670 860+ 
0002C4 4670 861+ 
0002C6 4670 862+ 
0002¢c8 4670 863+ 
0002CA 4670 864+ 
0002Cc 4670 865+ 
OO002CE 4670 866+ 
0002D0 4670 867+ 


BRANCH TABLE TO CONTROL PRINTING OF SHIP-VIA FIELD 


FDCTRL IF=(IND(2)), ON IF 'D' KEYED x 
GO TO=DELIVER i" 

-360N-CQ-490 - CHANGE LEVEL 3-A If IND = ON, 

DC X'4070* GENERATED CONSTANT go to FDFIELD I 

DC X°4672" GENERATED CONSTANT named DELIVER 
*, IJLF129 IND 2 TESTED 

Dc H'16496" GENERATED ARITHMETIC 

DC H' 16752" GENERATED ARITHMETIC 

Dc X°4070" GENERATED CONSTANT 

DC = X*407D' GENERATED constant] 'f!IND= OFF, 

DC X'4670* GENERATED CONSTANT g0 to next FOCTRL 

DC X'4670" GENERATED CONSTANT 

Dc X'4670" GENERATED CONSTANT 

DC X'4670" GENERATED CONSTANT 

DC X°4670' GENERATED CONSTANT 

DC X' 4670" GENERATED CONSTANT 

pc X¥'G670" GENERATED CONSTANT 

DC X'4670" GENERATED CONSTANT 

Dc X'4670' GENERATED CONSTANT 

DC X'4670" GENERATED CONSTANT 

pc X'4670" GENERATED CONSTANT 

DC X'4670" GENERATED CONSTANT 

DC X'4670" GENERATED CONSTANT 
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J035 


LOC OBJECT CODE 


0002D2 


0002D4 
0002D6 
0002D8 
0002DA 
0002DC 
0002DE 
0002E0 
0002E2 
0002E4 
0002E6 
0002E8 
OOO2EA 
0002EC 
0002EE 
0002F0 
0002P2 
0002F4 


JOB035 


SALES INVOICE 


ADDR1 ADDR2 STMT 


869 


870+* FDCTRL 


871 


1005 DELIVER 


SOURCE STATEMENT 


FDCTRL IF= (IND (3)), 
GOTO=PICKUP 
-360N-CQ-490 - CHANGE LEVEL 3-A 


* 


ON 


e 
*,IJLF110 END OF SEGMENT 4 


*,IJLF109 STARTING SEGMENT 5 


*, 


* 


*Pp* KEYED x 


e \ 
*,IJLF118 THIS SEGMENT ENTERED FROM SEGMENT 4 


X'4672¢* 


GENERATED 


CONSTANT 


*,IJLF129 IND 3 TESTED 


H' 16496° 
H*17008* 


X*4070# 
x*407D! 
X* 46708 
xX*4670° 
X°46708 
x*4670° 
X* 46708 
X*4670° 
x* 46708 
X*4670° 
x*4670° 
x*4670° 
xX*4670° 
xX*4670° 
xX*46708 


GENERATED 
GENERATED 


GENERATED 
GENERATED 
GENERATED 
GENERATED 
GENERATED 
GENERATED 
GENERATED 
GENERATED 
GENERATED 
GENERATED 
GENERATED 
GENERATED 
GENERATED 
GENERATED 
GENERATED 


FDCTRL IF=(IND(4)), 
GOTO=RREXP 


SS SS es "rr 


PDFIELD 61,80, 
SOURCE='DELIVER', 
SINK=PRT, 
JUSTIFY=C 


ARITHMETIC 
ARITHMETIC 


CONSTANT 
CONSTANT 
CONSTANT 
CONSTANT 
CONSTANT 
CONSTANT 
CONSTANT 
CONSTANT 
CONSTANT 
CONSTANT 
CONSTANT 
CONSTANT 
CONSTANT 
CONSTANT 
CONSTANT 


Use this 
if IND = OFF 


ON IF 'R* KEYED x 


SHIP-VIA POSITION x 
GET LITERAL sTRING |Branchto y, 
PUT TO SELECTRIC I1 |here from IT, 


CENTERED 


ne 


OOO45A 
OOO45SA 


00045C 


00042E 
OO042E 
000430 
000358 
0003E8 
OOO3EA 
0003A0 
0003A0 
0003A2 
00036A 
00036A 
00036C 
OO045E 
OO04S5E 


00036EF 
00036E 


4-20 


4070 


4770 
4475 


4770 
4475 


4770 
4475 


4770 
4475 


4475 


4671 


1290 
1291 
1292 
129 3+ 
12 94+ 
1295 
1296 
1297 
1298 


1300 BODY 


1301+*FDLINE 


1302+BODY 
1303 
1304 
1305 
1306 
1307 
1308 
1309 
1310 
1311 
1312¢ 
1313+ 
13144 
1315+ 
1316+ 
1317+ 
1318+ 
1319+ 
1320+ 
1321+ 
1322+ 
1323+ 
1324+ 
1325+ 
1326 
1327 
1328+¢ 
1329+ 


ORG 
DC 


*, IJLF143 SELECTRIC II PRINT REGION BEGINS AT 


* 


COLUMN 68, ENDS AT COLUMN 72 


e 

*,IJLF126 JUSTIFY OPTION FOR SINK 1 IS CENTER 
IJLF100041114 ORG TO DESIRED LOCATION TO ASM NEXT BYTE 
H*16496" GENERATED ARITHMETIC 


* 


eo 
*,IJLF128 SOURCE IS EMITTED 


*,IJLF145 SOURCE CHARACTER COUNT IS 5 


*, IJLF124 KIND IS UNRESTRICTED 


FDLINE 28,CYCLE= (28, AMOUNT,GROSS) PROVIDES FOR LINES 28-55 
-360N-CQ-490 - CHANGE LEVEL 3-A 
* *** TEST FOR DUPLICATE NAMES **#* 


EQU 


*, 


*, 

*, 

*, IJLF139 LINE NUMBER IS 28 

*,IJLF122 WIDTH IS 85 

*, IJLF123 LEFT MARGIN IS COLUMN 12 

*,IJLF123 RIGHT MARGIN IS COLUMN 80 

IJLF1000+1070 ORG TO DESIRED LOCATION TO ASM NEXT BYTE 
X*4770* GENERATED CONSTANT 

H* 17525" GENERATED ARITHMETIC 

IJLF1000+1000 ORG TO DESIRED LOCATION TO ASM NEXT BYTE 
X'4770" GENERATED CONSTANT 

H* 17525" GENERATED ARITHMETIC 

IJLF1000+928 ORG TO DESIRED LOCATION TO ASM NEXT BYTE 
X'4770" GENERATED CONSTANT 

H'17525" GENERATED ARITHMETIC 

IJLF1000+874 ORG TO DESIRED LOCATION TO ASM NEXT BYTE 
X°4770" GENERATED CONSTANT 

H'17525* GENERATED ARITHMETIC 

IJLF1000+1118 ORG TO ASM NEXT BYTE AFTER HIGHEST 
H*17525" GENERATED ARITHMETIC 

*, 

*, IJLF118 THIS SEGMENT ENTERED FROM SEGMENT 12 
IJLF1000+878 ORG TO DESIRED LOCATION TO ASM NEXT BYTE 
X°4671" GENERATED CONSTANT 


*,IJLF110 END OF SEGMENT 12 
*, IJLF109 STARTING SEGMENT 13 


J035 


LOC 


000370 
000372 
000374 
000376 
000378 
00037A 
00037C 
000375 
000 380 
000382 


0003A4 
OO03A4 
0003A6 
0903A8 
OOO3AA 
0003AC 
OOO3AE 
0003B0 
000382 
0003B4 
00038B6 
0003B8 


0003EC 
0003EC 
O003EE 
0003F0 
0003F2 
0003F4 
0003F6 
000 3F8 
OOO3FA 
0003FC 
0003FE 
000400 


000432 
000432 
000434 
000436 
0004 38 
00043A 
00043C 
00043E 
000440 
000442 
000444 
000446 


000460 
000460 
000462 
000464 
000466 
000468 
OOO4UGA 
00046C 


000540 


JOB035 


OBJECT CODE 


4070 
467D 
4670 
4670 
4670 
4670 
4670 
4670 
4670 
4670 


000540 4471 


000542 [4674 


OOO46A 


OOO046A 4070 
00046C 467B 


SALES INVOICE 


ADDR1 ADDR2 STMT 


1330+ 
1331+ 
1332+ 
1333+ 
13344 
1335+ 
1336+ 
1337+ 
1338+ 
1339+ 
1340 


1341 

1342+ 
1343+ 
1344+ 
1345+ 
1346+ 
1347+ 
1348+ 
1349+ 
1350+ 
1351+ 
1352+ 
1353+ 
1354 

1355 

1356+ 
1357+ 
1358+ 
1359+ 
1360+ 
1361+ 
1362+ 
1363+ 
1364+ 
1365+ 
1366+ 
1367+ 
1368 

1369 

1370+¢ 
1371+ 
1372+ 
1373+ 
1374+ 
1375+ 
1376+ 
1377+ 
1378+ 
1379+ 
1380+ 
1381+ 
1382 

1383 

1384+ 
1385+ 
13 86+ 
1387+ 
1388+ 
1389+ 
1390+ 
1391+ 


SOURCE STATEMENT 


H*16496* GENERATED ARITHMETIC 

H' 18045" GENERATED ARITHMETIC 

X*4670* GENERATED CONSTANT 

X*4670* GENERATED CONSTANT 

X'4670* GENERATED CONSTANT 

X*4670* GENERATED CONSTANT 

X*4670" GENERATED CONSTANT 

X*4670* GENERATED CONSTANT 

X*4670* GENERATED CONSTANT 

X*4670" GENERATED CONSTANT 

*, 

*,IJLF118 THIS SEGMENT ENTERED FROM SEGMENT 8 
IJLF1000+932 ORG TO DESIRED LOCATION TO ASH NEXT BYTE 
X'4671" GENERATED CONSTANT 

H*16496" GENERATED ARITHMETIC 

H' 17778" GENERATED ARITHMETIC 

X'*4670* GENERATED CONSTANT 

X*4670" GENERATED CONSTANT 

X*4670" GENERATED CONSTANT 

X* 4670" GENERATED CONSTANT 

X'4670" GENERATED CONSTANT J 
X*4670" GENERATED CONSTANT 

X*4670' GENERATED CONSTANT 

X'4670" GENERATED CONSTANT 

+, 

*, IJLF118 THIS SEGMENT ENTERED FROM SEGMENT 9 
IJLF1000+41004 ORG TO DESIRED LOCATION TO ASM NEXT BYTE 
X'4671" GENERATED CONSTANT 

H' 16496" GENERATED ARITHMETIC 

H*17271" GENERATED ARITHMETIC 

X'4670* GENERATED CONSTANT 

X'4670" GENERATED CONSTANT 

X*4670* GENERATED CONSTANT 

X'4670* GENERATED CONSTANT 

X*4670" GENERATED CONSTANT 

X'°4670* GENERATED CONSTANT 

X' 4670" GENERATED CONSTANT 

X'*4670" GENERATED CONSTANT 

+, 

*,IJLF118 THIS SEGMENT ENTERED FROM SEGMENT 10 
IJLP10004+1074 ORG TO DESIRED LOCATION TO ASM NEXT BYTE 
X'4671" GENERATED CONSTANT 

H'16496" GENERATED ARITHMETIC 

H' 16756" GENERATED ARITHMETIC 

X°4670" GENERATED CONSTANT 

X*4670" GENERATED CONSTANT 

X°4670* GENERATED CONSTANT 

X'4670" GENERATED CONSTANT 

X'4670* GENERATED CONSTANT 

X'°4670" GENERATED CONSTANT 

X*4670" GENERATED CONSTANT 


X'4670" GENERATED CONSTANT 


*, 


*,IJLP118 THIS SEGMENT ENTERED FROM SEGMENT 11 
IJLPF1000+41120 ORG TO ASN NEXT BYTE AFTER HIGHEST 
X'4673" GENERATED CONSTANT 

H*16496" GENERATED ARITHMETIC 

H' 16764" GENERATED ARITHMETIC J 

H'16496" GENERATED ARITHMETIC 

H' 16764" GENERATED ARITHMETIC | Cycle 

X'4670" GENERATED CONSTANT 

X' 4670" GENERATED CONSTANT 


H* 17521" GENERATED ARITHMETIC 
X'4674" GENERATED CONSTANT 
IJLF1000+1130 ORG TO DESIRED LOCATION TO ASM NEXT BYTE 
H'16496" GENERATED ARITHMETIC 
H' 18043" GENERATED ARITHMETIC 


IJLF100041344 ORG TO ASN NEXT BYTE AFTER HIGHEST 


Appendix D 421 


J035 JOB035 SALES INVOICE 


LOC OBJECT CODE ADDR1 ADDR2 STMT SCURCE STATEMENT 
1669 GROSS FDLINE 58 FOOTING LINE 
1670+*FDLINE -360N-CQ-490 - CHANGE LEVEL 3-A 
OO046E 1671+GROSS EQU * *** TEST FOR DUPLICATE NAMES *** 
000544 1672+ ORG IJLF10004#1348 ORG TO ASM NEXT BYTE AFTER HIGHEST 
000544 1673+ DC X'4675' GENERATED CONSTANT P——— 
1674 *, IJLF132 AT END OF CYCLE PRINT ELEMENT WAS L 
1675 *, POSITIONED ON LINE 56 OF FORM 
1676 *, 
1677 *,IJLF110 END OF SEGMENT 13 
1678 *,IJLF109 STARTING SEGMENT 14 Branch for 
1679 x, J 
1680 +, 
1681 *,IJLF139 LINE NUMBER IS 58 
1682 *,IJLF122 WIDTH IS 85 
1683 *,IJLF123 LEFT MARGIN IS COLUMN 12 
1684 *, IJLF123 RIGHT MARGIN IS COLUMN 80 
2146 *, 
2147 *,IJLF116 BUFFERS USED IN PATH 1 
2148 oe a eee ee ee 
2149 *, IJLF 130 STG 
2150 0,IJLP421 STG BUFFER MAY NOT HAVE BEEN USED AS 
2151 0, OUTPUT SINCE PRIOR INPUT 
2152 *, LJLP130 RDR/PCH 
0006 86 2153+ ORG IJLF1001#206 ORG TO ASM NEXT BYTE AFTER HIGHEST 
000686 4070 2154+ DC X'4070" GENERATED CONSTANT 
2155 *, 
2156 *,ITJLF118 THIS SEGMENT ENTERED FROM SEGMENT 14 
000000 2157+IJLF1000 CSECT 
000008 2158+ ORG IJLF1000+8 ORG TO DESIRED LOCATION TO ASM NEXT BYTE 
000008 0000 2159+ DC X'0000' GENERATED CONSTANT 
000014 2160+ ORG IJLF10004#20 ORG TO DESIRED LOCATION TO ASM NEXT BYTE 
000014 4070 2161+ DC H'16496" GENERATED ARITHMETIC 
000016 4070 2162+ DC H'16496" GENERATED ARITHMETIC 
000018 4070 2163+ DC H' 16496" GENERATED ARITHMETIC 
00001A 4472 2164+ DC H'17522" GENERATED ARITHMETIC 
2165 *, 
2166 *,IJLF146 PORM DESCRIPTION PROGRAM SPECIFIED 
2167 *, SELECTRIC II FORM HAVING 66 LINES 
0005B8 2168+IJLF1001 CSECT 
000688 2169+ ORG IJLF1001#208 ORG TO ASM NEXT BYTE AFTER HIGHEST 
000688 2170+ DC X'4679" GENERATED CONSTANT | 
00068A 4O1E 21714 DC X'4O1E" GENERATED CONSTANT 
00068C 4070407040704070 2172+ DC (134) x"40708 
000798 FFFFFFEFFFFF 2173+ DC 3H*-1" LAST SECTOR FLAG 
OOO79E FFFFFFFFFFFF 2174+ DC (2+1)H*-1" LAST CSECT FLAG 
000792 2175+ ORG *-4-2*1 
2176 *, 
2177 *, IJLF147 SUMMARY OF FDP-GENERATED DATA 
2178 #0000 ween enna 22 ------------------ --------- 
2179 *, UNPACKED FDP OUTPUT = 4 BLOCKS 
2180 *, 3735 DISK STORAGE = 3.4 SECTORS 
2181 *, 
2182 *,IJLF133 NO TERMINATING ERRORS FOUND IN THIS FDP 
2183 END 


4-22 


GR 0-7 
GR 8-F 
FP REG 


006880 
0068A0 
0068C0 
0068 E0 
006900 
006920 
006940 
006960 
006980 
0069A0 
0069C0 
0069E0 
006A00 
006A20 
006A 40 
006A60 


GR 0-7 
GR 8-F 
FP REG 


006880 
0068A0 
0068C0 
0068E0 
006900 
006920 
006940 
006960 
006980 
0069A0 
0069C0 
0069E0 
006A00 
006A20 
OO6A40 
00 6A 60 


NO wAME 


OO006EFO 
OO007BOA 


~ me ee 


3000 


447] 
een 2 70 


4475 
4572 


407440 
477040 
WO71447 


03/15/72 


QOOO006EDO O0006D0E 
OAOYO7TF1 8000617A 
00000000 00000000 


O0000C6C4 C6DEDID4 
45734475 42704476 
42704476 44744570 
42704570 44754572 
GQ47E4270 45744478 
SO72477F 467A4070 


00006692 
40006092 
00000000 


40400002 
GUY7FU5S72 
42704370 


QU 71 pee? 
oa7 
477 3 


45764C70 41784074 


G A 
5764070 44704174 


704070} 46724070 


40754070 
40704070 


46704670 46704670 46704670 47704472 
41784074 41744471 45764070 427C4074 


~_—_—-_ 


4075 
6174 Ty 
4475 


47704475 46714070 
44714076 41744370 
40704074 [417140 76 


417A4670 
44714076 
41704070 


43794379 477F4071 


45744070 407A4171 


43794270 43790000 00000000 93107C00 


NO NAME 03/15/72 

OOOO6EFO OOCO6EDO OOO0E6DCE 00006692 
OOOO7BOA OAOYOTF1 8000617A 40006092 
00000000 00000000 00000000 00000000 


O000C6C4 CB6DEDIDY 40400C02 
41714071 43714470 42704070 40704573 
40714576 40704475 41704075 40714576 
GY27TU407A 40754576 40704577 41714074 
GQ379477F GO O73 4C71417A 42704271 
42714071 “B27 40714574 42744071 
45724370 4: 271 45744470 4070)4672 
Ué 070 457 F 4670 4670 é 4670 
47704073 46714070 46784670 46704670 
47704271 47704171 46714070 47714670 
YOTO4OTD 47704271 47704074 46714071 
42714770 40714572 4O71407B 44714479 
45744170 4O7C4672 4C704770 44754671 
46704670 45724071 4OTTH4YTY 4Y4T5447C 
G7704475 46714070 46724670 46704670 
45704479 44730000 00000000 03107000 


PAGE 1 


0000667E 00006D78 9000612C 00005F98 
OOO06FDS pen 6648 jum 64A4 0000 pum 
00A80600 430500 FEY 0100 0000 [Om 


40704370 43724376] (44704070 40708070 


447D4270 43774378 4376 "27" 43724375 
43714371 4270447D 4575 Tay 45744270 
4572447D 44754474 4270 447544 76 


42704476 4474457 27 RUT TF] 4175417F 
41704672 407041 G Rte 45764070 
41744477] 457640 27C4074 41744271 
40734071 427A4270 42704071 447B4270 
4WO7D4770 44724671 40704371 46704670 
45764070 40744074 41744471 45764070 
4174's 847704071 45764070 44704074 
4670 Bem 46704670 46794679 46704076 
4174 42714770 40714176 40754078 
4O7A4076 45794379 427F4379 4379427F 
40774570 42704070 4070407B 40774379 


PAGE 2 


0000667E 00006D78 9000612c O00005F98 
OOO06FD8 60006648 800064A4 00000000 
00A80600 00A80500 00A90100 00000004 


40704379 43794379 4379477F 40704572 
40704171 407A4170 40714070 4O7A4077 
G“O7O447A 41744073 40714576 4070447D 
41704070 4Cee 74 43794379 427F4379 
4O7T1T4471 42 71 44744271 40714570 
GQU7KUK170 42 71 45704270 42744071 
40704170 4O070407D 47704271 47704073 
46704672 40704270 4O70407D 47704271 
46704670 46704672 40704370 4070407D 
46704670 46704670 46704672 40704470 
40724670 46704670 46704670 46704770 
45724270 44764572 44754479 44774478 
4O70467D 46704670 46704670 46704670 
4UTI94576 44754572 41704070 46724070 
46704670 46704670 46704572 40714077 


Appendix D 


4-23 


GR 0-7 
GR 8-F 
FP REG 


006880 
0068A0 
0068c0 
0068E0 
006900 
006920 
006940 
006960 
006980 
0069A0 
0069C0 
0069E0 
006A00 
006A20 
O06A40 
006A60 


GR 0-7 
GR 8-F 
FP REG 


006880 
O068A0 
0068cC0 
0068E0 
006900 
006920 
006940 
0C6960 
006A60 


4-24 


NO NAME 


OOO06EFO 
00007BOA 
00000000 


40704770 


~ 


OOQ006EDO 
OAO4KOTF1 
00000000 


0000CcbC4 
44754671 


GOT7F45 7 pee 714479 
4170 soi 724070 


4670457 


714075 


2 


4070417C 4070467B 
40734270 45704170 


QSTA4STA 
GS7A4271 
417E4374 
Y27A427A 
4O7A 4076 
47704472 
41794073 
4O70407B 
40714576 


NO NAME 


OOO006EFO 
OOO007BOA 
00000000 


Q379427E 
40734371 
40734070 
417B4076 
427E4379 
W27A427C 
40704070 
40704070 


GSTA4TTF 
4O7Z4477 
40724271 
W576427E 
GQ274427A 
45704179 
41704070 
40784274 
4C7C0000 


03/15/72 


0O0006D0E 
8000617A 
00000000 


C6D6D9D4 
40704377 
G4Y7C4577 
47704475 
45744572 
417B4073 
40724070 
40714077 
45724270 
417B4075 
43794379 
G27C4H27A 
40734170 
4O7A 4073 
G27A427A 
0C000000 


03/15/72 


00006692 
40006092 
00000000 


40400002 
46704670 
44714579 
46714070 
45754473 
43704570 
42724071 
GO72417A 
4O7T2447C 
43744570 
G77F4071 
427A427A 
GOTO4O7TA 
43794379 
G27A427C 
03107000 


O000667E 
O0006FD8 
00A80600 


4O7TO0447B 
46704670 
42704475 
41744670 
447B4170 
46714071 
45734072 
40704271 
44724071 
40724078 
45734071 
US76427E 
40734379 
4379477F 
G27A427A 


00006EDO 
OAOUOTF1 
00000000 


00006D0E 
8000617A 
00000000 


0000C6C4 C6DE6D9D4 


43794379 
43704370 
4O7A 4076 
42704570 
Y379477F 
G27TA427A 
--SAME-- 
4O70FFFF 


477F 4070 
44704072 
GQ274427A 
42704073 
40714573 
42704576 


FFFFFFFF 


00006692 
40006092 
00000000 


40400002 
45734073 
40744070 
W27C4U27A 
GO7O40TA 
40734179 
427E4379 


03107000 


0000667E 
00006 FD8 
00A 80600 


4070457B 
GI71407A 
47704071 
G27A427A 
40764274 
407A4170 
4379477F 


C0006D78 
60006648 
00A80500 


42704575 
46704670 
45784570 
46704670 
40704672 
46704072 
GI7T94O7A 
4OT244H75 
417E4075 
40714070 
GI794O07A 
43794379 
43794379 
42714573 
427A4576 


00006D78 
60006648 
00A80500 


41794073 
44704078 
45734074 
4576" AY7In 
427A 
4070 
4070(4679] 


9000612C 
800064A4 
00A 90100 


45704170 


46704670 | 


45724475 
4670467 
44754 673 
40704272 
41704070 
44714271 
41794270 
GO7A4075 
45704270 


PAGE 3 


00005F98 
00000000 
00000004 


40704672 


es 4071 
'y Pee 

467 
4OTO41IC 
40714178 


4O7A4073 
KOT724474 


fe MO OBMaeai. ass 


K77F4471 [46744675 


G27F477F 
40734171 
427E4 379 


40704571 
407A4170 
4379477F 


PAGE 4 


9000612C 
BO00064A4 
00A90100 


41704070 
4OT44070 
GI79407A 
43794379 
G27A427A 
40784274 
401E4070 


0O0005F98 
00000000 
00000004 


407A4073 
45724171 
45704270 
477F4071 
427A4576 
G27A427A 
40704070 


Hho & 


303236 


0018 


Buffer 
Start 
Position 
Relative 
to 4, Zero 
Origin 


03 


Data Type 
Byte for 
Validity 

& Function 
Bytes to 
Follow 


Compare 
Byte = 
EQ 


FID=026 


PACKING=DE LIMIT 


Form Length is 66 Lines 


Begin Tab Definition 


Begin The FCD 


FDFIELD (ADDRESS 1) Specification 


41 


End 

Control 
Indicator 

= New Line 1 


20 
Validity Function 
Byte, Byte for 
Value COMPARE 
Check 
Follows* 


00 


End 
Control 
Indicator 
= Space 
zero 


* Specifies enter mode required, fixed length records. 


Appendix D 4-25 


110610000A 0659 392F 39392F 39397F a FDFIELD (DATEFLD) Specification 


11 10 00 OA 


Data Type Function Data Sink Selectric 
Byte for Byte for Byte for Sink Byte 
Numeric Data Sink PRT Selectric for EDIT 
Function Group Bytes and PRT 
Byte to to Follow 

Follow 


06 59392 F 39392F 3939 7F 


PICTURE PICTURE = Y9/99/99 PICTURE 
Digit Delimiter 
Count = 

6 


620010000D7021700361005F G060606060606E2. .. 


> FDCTRL IF = (IND (2)), GOTO=DELIVER Specification 


62 00 000D 


GOTO On Condition Branch (IND = OFF) If IND = OFF, 
Condition Byte = NOT Displacement Branch to the 
=+13 Next FDCTRL Macro 


7021700361005 F 606060606060 62... 


If IND =ON, Branch to the FDFIELD Next FDCTRL 
Macro Named DELIVER Macro 


63001C001CO06B > CYCLE Beginning at FDLINE (BODY) Specification 


001C 001C 006B 


Number Number of Displacement 

of Lines Repetitions to FDLINE Macro 
in Cycle in Cycle Named GROSS 

= 28 = 28 


Repeat Cycle Byte 


End Cycle Byte (in FDLINE Named GROSS) 


End Form Byte (in CSECT Named IJLF 1001) 


4-26 


Glossary 


The following terms are defined as they are used in this manual. If 
you do not find the term you are looking for, refer to the index or 
to the JBM Data Processing Glossary, GC20-1699. 

IBM is grateful to the American National Standard Institute 
(ANSI) for permission to reprint its definitions from the American 
National Standard Vocabulary for Information Processing (copy- 
tight © 1970 by American National Standards Institute, Incorpo- 
rated), which was prepared by Subcommittee X3.5 on Terminology 
and Glossary of American National Standards Committee X3. 


Access lines. The communication lines that join the central com- 
puter and the remote terminal to common-carrier exchange 
equipment. 


Access method. A combination of an access technique (either 
queued or basic) and a given data set organization (for instance, 
sequential, partitioned , indexed sequential, or direct) that allows the 
transfer of data between main storage and I/O devices. 


Array. An arrangement of elements in one or more dimensions.* [pn 
this publication, an array is an arrangement of all the bits of a partic- 
ular global variable. For example, the &PIB array contains 48 sepa- 
rate bits: &PIB(1), &PIB(2) and so forth. 


ASCII, American Standard Code for Information Interchange. The 
standard code, using a coded character set consisting of 7-bit coded 
characters (8 bits including parity check), used for information inter- 
change among data processing systems, communication systems, and 
associated equipment. The ASCII set consists of control characters 
and graphic characters.* 


Assemble. To prepare a machine language program from a symbolic 
language program by substituting absolute operation codes for sym- 
bolic operation codes and absolute or relocatable addresses for sym- 
bolic addresses.* 


Assembler. A computer program that assembles.* 


Authority. The extent of a macro statement through an FD pro- 
gram until the same type of macro statement (or one of higher 
authority) appears later in the FD program. 


Binary synchronous communications (BSC). Data transmission in 
which character synchronization is controlled by timing signals gen- 
erated by the device that originates a message (and the device that 
obtains the message recognizes the sync pattern at the beginning of 
the transmission - the devices are locked in step with one another). 


BSC. See binary synchronous communications. 


Common carrier. A company that furnishes communication services 
to the general public and is regulated by appropriate local, state, or 
federal agencies. 


Communication line. The medium over which data signals are trans- 
mitted. 


Control character. A character whose occurrence in a particular con- 
text initiates, modifies, or stops a control operation - for example, a 
character to control carriage return.* 


Control section. The smallest separately relocatable unit of a pro- 
gram. That portion of text specified by the programmer to be an 
entity, all elements of which are to be loaded into contiguous main 
storage locations. 


* American National Standard Definition 


Copy book. Source language coding that is copied, via a COPY 
instruction, from a library and is included in the program currently 
being assembled. A member of a partitioned data set can be copied 
from either the system macro library or a user library concatenated 
to it. 


Delimiting macro. The FDEND Form Description macro statement 
that closes the description of each form and prepares for a form 
description that may follow. 


Diagnostic macros. The optional FDTRACE and FDDSPLY Form 
Description macro statements that provide a trace facility and a dis- 
play facility for aid in diagnosing error conditions. 


Encoder. Person who designs and defines forms by coding Form 
Description macro statements. 


FCD. See Field control descriptor. 

FD macro, See Form Description macro. 

FD program. See Form Description program. 
FD utility. See Form Description utility. 


Field control descriptor. In the 3735 terminal, the part of a Form 
Description program that the 3735 interprets as the directions for 
the processing of one data field or the performance of one logical or 
device-control operation. 


Form Description macro. One of a set of specialized macro instruc- 
tions with which a forms encoder can describe symbolically the 
structure of a data processing form, the characteristics of each field 
on the form, and the processing to be done on each field by the 
3735 terminal and its operator. 


Form Description program. A set of control information interpreted 
or executed by the 3735 terminal or other processor as the complete 
set of instructions for the processing of one type of form. 


Form Description utility. A computer program that restructures one 
or more object modules obtained from the assembly of FD macro 
statements into unpacked program blocks (UPBs) and writes the 
blocks into a user’s data set. 


Forms encoder. See encoder. 


Global variable. SET symbols defined in one macro definition used 
to vary the statements that appear in other macro definitions. 


Identification (ID) characters. Characters sent by a BSC terminal on 
a switched line to identify the terminal. 


Inner macro. Macro statement called by an outer (external) macro 
or by another inner (internal) macro. 


Keyed unpacked program block (K UPB). A physical 486-byte block 
of auxiliary storage containing a subset of an FD program that 
results from the assembly of a set of FD macro statements describing 
one type of form to be processed. 


Macro definition. A set of statements that provides the assembler 
with: (1) the mnemonic operation code and the format of the 
macro instruction, and (2) the sequence of statements the assembler 
generates when the macro instruction appears in the source program. 


MNOTE message. A message appearing on the diagnostic listings 
that result from the assembly of macro statements. The message 
provides diagnostic information regarding coding errors in the macro 
statements and provides descriptive information for verifying the 
correctness of each macro specification. 
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Modulo, The remainder after any division has been performed. 


Multipoint line. A communication line that connects more than one 
terminal; also known as multidrop line. 


Nonswitched line, A communication line that connects a terminal 
and the computer for a continuous period or for regularly recurring 
periods of time at stated hours for the exclusive use of one installa- 
tion; also known as a private, leased, or dedicated line. 


Object module. A module that is the output of an assembler or 
compiler and is input to a linkage editor.* 


Outer macro. Macro statement specified externally by the 3735 
forms encoder. 


Path. One portion of an FD program created by one of the follow- 
ing actions: (1) the start of the FD program; (2) the encoding of 
the SAVELOC operand outside of a cycle; (3) the joining of two 
paths. 


Point-to-point line. A communication line that connects a single 


remote terminal to the computer. It may be either switched or non- 
switched. 


Procedural macro, The FDCTRL Form Description macro that 
enables the checking of terminal control program status. 


Promotability. The ability of a keyword operand to be coded in 
some particular macro instruction and also to be coded in one or 
more macros of higher authority. 


Resource. Any system facility that is required by a job or task; for 
example, main storage, I/O devices, data sets. 


Scope. The extent of a structural FD macro instruction through the 
form description until the same type of macro statement (or a macro 
statement of a higher level) appears later in the description. Also 
called authority. 


* American National Standard Definition 


4-28 


Segment. A part of a computer program which has structure such 
that the program can be executed without the entire program being 
in internal storage at one time. Several conditions create the seg- 
ments comprising a path of an FD program: (1) the start of a path; 
(2) the issuance of a branch; (3) the creation of a cycle; (4) the 
encoding of aSAVELOC operand within a cycle; (5) the appearance 
of the post-limit macro; (6) the joining of several segments in the 
path. 


Structural macro. One of four Form Description macro statements 
(FDFORM, FDPAGE, FDLINE, or FDFIELD) that define the struc- 
tural organization of a form and the processing required by each 
field in the form. 


Switched line. A communication line on which the connection 
between the computer and a remote terminal is established by dial- 
ing; also known as a dial or dial-up line. 


Target. The name specified on the subsequent outer FD macro that 
is to be processed when cyclic or GOTO processing is either com- 
plete or stopped by the 3735 operator. 


Telecommunications. Any transmission or reception of signals, writ- 
ing, sounds, or intelligence of any nature, by wire, radio, or other 
electromagnetic media. 


Teleprocessing. The processing by a computer of data entered at a 
remote terminal. 


Terminal. A point in a system at which data can enter, leave, or 
enter and leave;* also a control unit to which one or more I/O 
devices can be attached. 


Terminal control program. The microcoded control program 

recorded in the terminal control unit during manufacture of the 
3735 that interprets FD programs as a set of directions for pro- 
cessing one type of form and provides detailed terminal control. 


Transmission. The transfer of coded data by an electromagnetic 
medium between two points in a telecommunications network. 


Unpacked program block (UPB). A physical 476-byte block of secon- 
dary storage containing a subset of an FD program suitable for trans- 
mission to the 3735 terminal. 


Variable. See global variable. 
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